Create hard parameters for graphviz attributes?

[2br-2b]

When creating a Graphviz graph, there isn't any documentation for the parameters built into the system, which means there's no intellisense and no way to see what parameters exist or what their valid values are.

The currently best way for a beginner is to go to the official documentation for graphviz (for example, https://graphviz.org/docs/edges/) to see the possible values and set them there, but it would be easier to have built-in enums. For example, here's how I am creating my edges:

class ArrowStyle(Enum):
    FORWARD = "forward"
    BACKWARD = "back"
    BOTH = "both"
    NONE = "none"

class JwEdge(pydot.Edge):
    def __init__(self, source_id: str, destination_id: str, arrow_direction: ArrowStyle = ArrowStyle.NONE):
        super().__init__(
            src=source_id,
            dst=destination_id,
            dir=arrow_direction.value,
            )

On one hand, this makes it easier for me to create edges; on the other hand, I don't know how static Graphiz's api is, so having an attribute there that might not be supported for a specific version could lead to other issues.

Related to #130

[lkk7]

Yeah, that's a difficult thing to solve.
I also like Intellisense and typing wherever possible, but keeping up with all the attributes, possible values, and types is an unrealistic effort for me now.
And as you said, there's the problem of having different versions of Graphviz (even though it's probably very stable now, you never know what's going to happen or what weird version someone will use).

[ferdnyc]

And as you said, there's the problem of having different versions of Graphviz (even though it's probably very stable now, you never know what's going to happen or what weird version someone will use).

This isn't just a theoretical concern, either. There are extant cases where graphviz takes undocumented or conflictingly-documented values for certain attributes, which create a real difficulty for PyDot to handle sensibly.

[ferdnyc]

The other tricky thing here is, if this were to be implemented, the corresponding getters and setters would really need to be defined using the enums as their output/input types (respectively). Whereas, currently, all of those methods are generated from lists of names (and, of course, therefore generated untyped) at class definition time.