Store Subgraph and Cluster edge points by name #238
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Commit message:
When instantiating a new
Edge
, if the caller supplies aSubgraph
orCluster
object as an edge point, store only the name string of that object, same as we do forNode
objects as edge points.According to the DOT Language definition (1) an edge point may be a node or a subgraph. Clusters are just subgraphs whose names begin with
cluster
, so those are also allowed.Although not documented, the
Edge
constructor already accepts subgraphs and clusters as edge points as long as they are in the form of name strings. These strings are stored inEdge.obj_dict['points']
and get included in the writing of a DOT string (Edge.to_string()
), just as name strings of nodes would.However, until now, this is different when an edge point is supplied as an object. For a
Node
, the name string gets looked up and stored inEdge.obj_dict['points']
, butSubgraph
andCluster
objects are stored there directly as objects.This leads to problems when
Edge.to_string()
tries to concatenate the different parts of the edge, with errors like:I did not find any explanation for the difference, nor any code that depends on the points being stored as objects.
The alternative of storing objects across the line was not chosen, because it would have much larger implications both for the pydot code itself as for existing user code. Worth considering for the long term maybe, but this commit provides a bug fix in the current context.
Fixes #89.
Further remarks:
@prmtl @ankostis or others: Reviews/comments still very much welcome of course!