You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From what I can tell MarathonObject et al. are basically record types, but they unfortunately don't have a __hash__ method so in Python3 you can no longer put them in dictionaries or sets, for example:
obj = MarathonObject()
collection[obj] = ...
Works fine on Python 2.7 (because it's using literal identity) but Python3 correctly complains since MarathonObject implements __eq__ but not __hash__.
We pretty frequently put MarathonTasks in sets and such to figure out which tasks are running or not in PaaSTA, so ... either we can refactor PaaSTA to actually have a wrapper type around the types that marathon-python is trying to do, or we can define hash on the MarathonObject class.
I think the right answer is that marathon-python should use a proper record type like namedtuple or something really cool like PRecord. The ok answer would be to just define __hash__ to be the hash of the json representation (which is meh because the object can be mutated so the hash could change which is bad).
I don't want to unilaterally add a dependency on pyrsistent, but I really think that a proper record type instead of hand rolled object hierarchies would be much better.
The text was updated successfully, but these errors were encountered:
From what I can tell MarathonObject et al. are basically record types, but they unfortunately don't have a
__hash__
method so in Python3 you can no longer put them in dictionaries or sets, for example:Works fine on Python 2.7 (because it's using literal identity) but Python3 correctly complains since MarathonObject implements
__eq__
but not__hash__
.We pretty frequently put MarathonTasks in sets and such to figure out which tasks are running or not in PaaSTA, so ... either we can refactor PaaSTA to actually have a wrapper type around the types that marathon-python is trying to do, or we can define hash on the MarathonObject class.
I think the right answer is that marathon-python should use a proper record type like namedtuple or something really cool like PRecord. The ok answer would be to just define
__hash__
to be the hash of the json representation (which is meh because the object can be mutated so the hash could change which is bad).I don't want to unilaterally add a dependency on pyrsistent, but I really think that a proper record type instead of hand rolled object hierarchies would be much better.
The text was updated successfully, but these errors were encountered: