[Python-Dev] For Python 3k, drop default/implicit hash, and comparison

Jim Fulton jim at zope.com
Sun Nov 6 17:15:58 CET 2005


The recent discussion about what the default hash and equality comparisons
should do makes me want to chime in.

IMO, the provision of defaults for hash, eq and other comparisons
was a mistake.  I'm especially sensitive to this because I do a lot
of work with persistent data that outlives program execution. For such
objects, memory address is meaningless.  In particular, the default
ordering of objects based in address has caused a great deal of pain
to people who store data in persistent BTrees.

Oddly, what I've read in these threads seems to be arguing about
which implicit method is best.  The answer, IMO, is to not do this
implicitly at all.  If programmers want their objects to be
hashable, comparable, or orderable, then they should implement operators
explicitly.  There could even be a handy, but *optional*, base class that
provides these operators based on ids.

This would be too big a change for Python 2 but, IMO, should definately
be made for Python 3k.  I doubt any change in the default definition
of these operations is practical for Python 2.  Too many people rely on
them, usually without really realizing it.

Lets plan to stop guessing how to do hash and comparison.

Explicit is better than implicit. :)

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Python-Dev mailing list