keying by identity in dict and set

[dieter]

Steve White <stevan.white at 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.