[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