-
Notifications
You must be signed in to change notification settings - Fork 147
generate __eq__ for Python messages #281
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
Conversation
|
can you clarify the context/motivation for this? |
|
Without two message instances can't easily be compared if they contain the same values. The user would need to compare each and every field (as well as recursive fields) manually. Also if the message later changes and a field is added the existing checks would be incorrect. |
|
I found this article with a good overview: https://hynek.me/articles/hashes-and-equality/ |
|
Should we remove the |
|
From: https://docs.python.org/3.5/reference/datamodel.html#object.__hash__
I think it's right to implement |
Done in 2756c3f. |
|
FWICT ros1 time msg types are hashable: https://github.com/ros/genpy/blob/b244f2f50813ce0385c8673a899bce9e140a35d8/src/genpy/rostime.py#L127..L131 which might cause migration issues to ros2 for some code (unless times in ros2 are immutable? I don't think so). Not much to change, just an observation that came up from the hashable discussion which might be worth adding to the migration guide? |
Treating Python message classes as data (same as in C++) and implementing
__eq__andbased on all the fields.__hash__CI for Linux only: