-
Notifications
You must be signed in to change notification settings - Fork 160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cluster to cluster edge fails #89
Comments
When instatiating a new `Edge`, if the caller supplies a `Subgraph` or `Cluster` object as an edge point, store only the name string of that object, same as we do for `Node` 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 in `Edge.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 in `Edge.obj_dict['points']`, but `Subgraph` and `Cluster` 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: TypeError: unsupported operand type(s) for +: 'Subgraph' and 'str' TypeError: sequence item 2: expected str instance, Cluster found 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 user code accessing `Edge.obj_dict['points']` directly. Fixes pydot#89. [1]: https://www.graphviz.org/doc/info/lang.html
When instantiating a new `Edge`, if the caller supplies a `Subgraph` or `Cluster` object as an edge point, store only the name string of that object, same as we do for `Node` 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 in `Edge.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 in `Edge.obj_dict['points']`, but `Subgraph` and `Cluster` 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: TypeError: unsupported operand type(s) for +: 'Subgraph' and 'str' TypeError: sequence item 2: expected str instance, Cluster found 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 user code accessing `Edge.obj_dict['points']` directly. Fixes pydot#89. [1]: https://www.graphviz.org/doc/info/lang.html
I ran the example code, which gave me the following error in Python 3:
In Python 2, the error is:
The error complains about one of the edge points being a I did not find any explanation for this difference. The DOT Language definition defines that both nodes and subgraphs can be points of an edge. A cluster is just a specific kind of subgraph, as also described there. The reason this bug does not seem to get run into very often is, I think, twofold:
Anyway, I have prepared PR #238 to remove this difference by always storing Some further remarks about the example code:
Then finally, when all the fixes in pydot and the example code are in place, the end result will look the same as in the Graphviz example: Versions: pydot 1.4.1, python 3.7.3. Mentioning same issue in earlier fork pydot-ng: pydot/pydot-ng#25. |
When instantiating a new `Edge`, if the caller supplies a `Subgraph` or `Cluster` object as an edge point, store only the name string of that object, same as we do for `Node` 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 in `Edge.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 in `Edge.obj_dict['points']`, but `Subgraph` and `Cluster` 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: TypeError: unsupported operand type(s) for +: 'Subgraph' and 'str' TypeError: sequence item 2: expected str instance, Cluster found 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 pydot#89. [1]: https://www.graphviz.org/doc/info/lang.html
What steps will reproduce the problem?
To see if I'm it's possible to get the dependency graph from VCL/Delphi
project, I'm trying to reproduce this example
http://www.graphviz.org/content/fdpclust (directed)
everything works well, until it come to add edges on clusters then it fail.
(e-> clusterB and clusterC -> clusterD)
What version of the product are you using? On what operating system?
pydot 1.0.28 (patched so it find Graphviz in "Program Files (x86), python 3.3,
Windows 7 64 bits.
Joined : the function I use to produce the graph,
Original issue reported on code.google.com by
[email protected]
on 7 Mar 2014 at 10:41Attachments:
The text was updated successfully, but these errors were encountered: