Implement __hash__ and __eq__ for cuda.core classes - #1198
Conversation
…lasses, enabling their use as dictionary keys and in sets.
|
/ok to test eeef948 |
|
+1 for this change. Longer term, it would be great to achieve this sort of thing with a mix-in class. I think what gets in the way is some internal inconsistency, e.g., using |
This comment has been minimized.
This comment has been minimized.
What would be the benefit of using a mixin? I feel like it would require a bunch of machinary of parameterize it to the point it solves the problems you pointed out (ie. being able to handle different handle member names) |
Co-authored-by: Oleksandr Pavlyk <21087696+oleksandr-pavlyk@users.noreply.github.com>
|
/ok to test 714091c |
…a-python into rparolin/cuda.core.hashable
|
/ok to test fff600c |
|
/ok to test 8227c21 |
|
/ok to test b8cc00d |
|
/ok to test af5c52e |
|
/ok to test 8c9900d |
|
/ok to test 95047e4 |
| # ============================================================================ | ||
| # Context Equality Tests | ||
| # ============================================================================ |
There was a problem hiding this comment.
It would probably be difficult, but is there any way we can add a test for when we have different contexts and/or an invalid context in some way?
mdboom
left a comment
There was a problem hiding this comment.
My comments aren't requirements -- I mostly defer to previous reviewers here.
… and hash behaviour is consistent.
|
/ok to test ae74733 |
|
/ok to test 98e8fe0 |
|
Implement
__hash__and__eq__for cuda.core classesThis PR implements
__hash__()and__eq__()methods for cuda.core classes (Stream, Event, Context, Device), enabling them to be used as dictionary keys and in sets.Fixes #664