[Python-ideas] An identity dict

Benjamin Peterson benjamin at python.org
Wed Jun 2 19:38:46 CEST 2010

Raymond Hettinger <raymond.hettinger at ...> writes:
> None of the presented examples take advantage of that property.
> All of them work with regular dictionaries.   This proposal is still
> use case challenged.

Besides that ASPN recipe of mine I mentioned before [1], here are some
more examples:

- copy.deepcopy() and pickle use it for an object memo.

- keeping track of protocol versions in Twisted. [2]

- memo in a serialization protocol. [3]

[2] http://twistedmatrix.com/trac/browser/trunk/twisted/persisted/
[3] http://twistedmatrix.com/trac/browser/trunk/twisted/spread/jelly.py

> AFAICT from code searches, the idea of needing to override
> an existing __eq__ with an identity-only comparison seems
> to never come up.  It would not even be popular as an ASPN recipe.
> Moreover, I think that including it in the standard library would be
> harmful.
> The language makes very few guarantees about object identity.
> In most cases a user would far better off using a regular dictionary.
> If a rare case arose where __eq__ needed to be overridden with an
> identity-only check, it is not hard to write d[id(obj)]=value.  

On the other hand, d[id(obj)] can be dangerous and incorrect on CPython:

>>> d = {}
>>> d[id([])] = 10
>>> d[id([])]

> Strong -1 on including this in the standard library.

How do you feel about Antoine's keyfuncdict proposal?

> Raymond
> P.S.  ISTM that including subtly different variations of a data type
> does more harm than good.   Understanding how to use an
> identity dictionary correctly requires understanding the nuances
> of object identity,

We're all adults here. We provide WeakKeyedDict and friends even though
they rely on unpredictable and subtle garbage collection.

> how to keep the object alive outside the dictionary
> (even if the dictionary keeps it alive, a user still needs an
> external reference
> to be able to do a lookup), and knowing that the version proposed for
> CPython has dramatically worse speed/space performance than
> a regular dictionary.  The very existence of an identity dictionary in
> collections is likely to distract a user away from a better solution
> using: d[id(obj)]=value.

I would argue that that's not a better solution given the above example.
Anyone using id(obj) would have understand the nuances of object identity
perhaps more than a real identity dictionary.

More information about the Python-ideas mailing list