Steve White <stevan.wh...@gmail.com> writes: > Regarding my question > "Is there some fatal reason that this approach must never be > used, besides the lack of documentary support for it?" > If finally dawned on me that there is a use-case for containers that > would preclude using object identity for keys. That is, if the object > is to be serialized, or otherwise stored past the run-time of the > program. Of course, all the identities (all the id() values) will be > meaningless once the current run ends.
One motivation to base dict key management on equality (rather than identity) are literals: Consider a dict "d" with at some place `d["my example key"] = 1` and at a different place (maybe another function, another module) you access `d["my example key"]`. You would expect to get `1` as result as for your eyes the two literals are equal. Would the key management be based on identity, then you could get either the expected `1` or a `KeyError`. The reason: Python does not manage (most) literals globally; this means, if you use the same literal in different places you may (or may not) have non-identical objects. Basing on equality, you are also more flexibal than with identity, because can can change the equality rules for a class while you cannot change the identity rules. Thus, if you need identity based key management, define your `__eq__` accordingly. -- https://mail.python.org/mailman/listinfo/python-list
