Conversation
29b5e36 to
de7f0d8
Compare
Use unique numerical index instead of string (which might cause issues when using pin names that are not unique when ignoring upper/lower case).
de7f0d8 to
1127bcb
Compare
There was a problem hiding this comment.
I like your implementation with a few simple changes to obtain unique port numbers, but I also suggest using one-based port numbers to keep them identical to the pin numbers in the typical case as you describe in #160 (comment). Adding +1 at four locations is enough to ensure this.
If you agree to this, it might also be wise to name the variables pinindex (or pinidx if it must be short) instead of pinid when they contain zero-based pin index numbers. What do you think?
I also suggest updating the type hints of the Cable.connect() parameters and the Connection attributes to reflect their new pin index usage:
PinIndex = int # Zero-based pin index
NoneOrMorePinIndices = Union[PinIndex, Tuple[PinIndex, ...], None] # None, one, or a tuple of zero-based pin indicesso that in the standard case, internal pin IDs match the actual connector's pin numbers, which usually start from 1. Co-authored-by: kvid <kvid@users.noreply.github.com>
as suggested by @kvid. Co-authored-by: kvid <kvid@users.noreply.github.com>
as suggested by @kvid. Co-authored-by: kvid <kvid@users.noreply.github.com>
|
I have implemented your suggestions, please have a look at the updated code. |
13658cb to
afd4147
Compare
|
My change suggestions have been implemented, and the test cases mentioned in #160 seems to be handled as expected now. When building examples, the |
The change will instead be logged in the `doc/changelog` branch
Closes wireviz#160. Co-authored-by: kvid <kvid@users.noreply.github.com>
Closes #160.
Use unique numerical index instead of string (which might cause issues when using pin names that are not unique when ignoring upper/lower case).
This does not address the issue of having special HTML characters as part of pin names, labels, etc. as mentioned in #160 and now listed as #230; there should be a separate PR dealing with escaping these entities in the GraphViz HTML (e.g.
>to>).