This does not effect any released version. I just wanted to jot down some thoughts about this design pitfall that I almost made with this library back when I first started it.
The behavior which I originally documented in the docstring of __eq__, but luckily accidentally did not implement, was that hardware address instances were equal if one was a subclass of the other (unless the subclass had a different size for some reason).
Now that sounds pretty reasonable at face value, doesn't it? Substitution principle - subclass instances should be usable as a parent class instance, and that includes equality.
I even implemented the "fixed" version (but never merged or released) in commit bdb4d260a767d821a84ce8d903e9eb45af143443, in case you want to play with it.
Here's the thing though: it would've resulted in this behavior:
That should raise some alarms. foo == bar == qux is true but foo == qux == bar is false!?
This kind of inconsistency would've been a terrible API pitfall - most users would not expect equality to work this way, and the common case would absolutely lead to people forming expectations that equality is transitive.
This does not effect any released version. I just wanted to jot down some thoughts about this design pitfall that I almost made with this library back when I first started it.
The behavior which I originally documented in the docstring of
__eq__, but luckily accidentally did not implement, was that hardware address instances were equal if one was a subclass of the other (unless the subclass had a different size for some reason).Now that sounds pretty reasonable at face value, doesn't it? Substitution principle - subclass instances should be usable as a parent class instance, and that includes equality.
I even implemented the "fixed" version (but never merged or released) in commit bdb4d260a767d821a84ce8d903e9eb45af143443, in case you want to play with it.
Here's the thing though: it would've resulted in this behavior:
That should raise some alarms.
foo == bar == quxis true butfoo == qux == baris false!?This kind of inconsistency would've been a terrible API pitfall - most users would not expect equality to work this way, and the common case would absolutely lead to people forming expectations that equality is transitive.