To be honest, given how easy it is to key a current dict off of object id, I don't see much real value in creating a separate dict type that does it by default. But as long as it's an addition, rather than a change to existing behavior, then the only real problem with it is the standard "makes the language bigger".
Something which used different behaviour at C-level could be a fair bit faster, since it wouldn't have to jump back into the eval loop all the time when looking up the hash or comparison functions. Passing id() into the dictionary isn't so good either, as you have to make the function call on every item lookup, and you can't effectively iterate over the contents of the dictionary.
Its utility might be more obvious as a set variant rather than a dictionary variant, though, as the best use I can see for it is in using sets to classify mutable objects like lists (such as Antoon's example of applying special processing to certain graph points).
Cheers, Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
