Document persistency and equality #220
Conversation
There was a problem hiding this comment.
I think this nails it. Maybe a short example, addressing the last paragraph would help to get it out of grey theory, like
>>> def function1():
... class IMyInterface(Interface):
... pass
... return IMyInterface
...
>>> def function2():
... class IMyInterface(Interface):
... pass
... return IMyInterface == function1()
...
>>> function2()
True
@jensens I added an example. I did not use your example because it is very rare to compare interfaces directly in application code. Equality checks happen indirectly, for example inside |
There was a problem hiding this comment.
Thank you for this!
I'm a +0 on it.
On the entirely positive side, I appreciate the explanation for some of the motivation for the comparison and hashing behaviour.
On the 0 side, I feel like the example of the possible hazards for the unwary, would be better made a part of the existing documentation for this behaviour, where there's already one such example. This is especially the case because the example doesn't actually work with persistence.
I'm happy to prepare a PR like that, incorporating the motivation and new example from this PR.
I'm not unhappy enough to ask that this one not be merged.
|
Jason Madden wrote at 2020-10-21 04:34 -0700:
@jamadden commented on this pull request.
...
Thank you for your detailed review!
I will soon (likely in the next week) incorparate your suggestions.
...
On the 0 side, I feel like the example of the possible hazards for the unwary, would be better made a part of [the existing documentation](https://zopeinterface.readthedocs.io/en/latest/api/specifications.html#equality-hashing-and-comparisons) for this behaviour, where there's already one such example. This is especially the case because the example doesn't actually work with persistence.
I would not mind to refer to an example elsewhere in the documentation.
You are right that the example does not work with persistence.
In my view, this is not a drawback: surprising effects can
happen without any persistence involved.
I'm happy to prepare a PR like that, incorporating the motivation and new example from this PR.
Great!
I would not mind, however, if you would directly improve the
existing PR rather than make you own one.
...
Classes, however, are inconsistent, or at least inconvenient: They compare and hash by identity (and can't be sorted) but pickle by global identifier, meaning that the value of `==` can change.
I do understand this:
classes are first class citizens in Python; they are often
defined non globally and it is important that classes defined
at different "places" in the same module which happen to have
the same name are not compared equal.
Persistency is a secondary aspect for classes (a high percentage of
the Python users likely does not use `pickle`).
Consequently, `pickle` just insists that classes involved in
pickles must be defined globally (and the "right" one must be found
via the lookup).
...
However, `obj` cannot actually be pickled. So this may not be the best example of persistence.
It was not designed as a persistency example but as an example
for the equality definition causing surprises.
|
…how this relates to equality/hashing/sorting.
I took you at your word and added some commits to this. (Whoops, at this writing realising I missed one, coming soon) In an earlier comment I suggested that maybe it was good not to get into the weeds of pickle too much (that is, go into too much unnecessary detail). But as I was working on this, I found that actually giving some concrete details about pickle helped structure the discussion. Let me know how I can clarify or simplify. |
|
@jamadden Thank you for the great introduction to class and interface persistence and the examples demonstrating potential caveats of the |
Documentation related to #218