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

[Guido van Rossum]

On 11/6/05, Jim Fulton <jim at zope.com> wrote:
> IMO, the provision of defaults for hash, eq and other comparisons
> was a mistake.

I agree with you for 66%. Default hash and inequalities were a
mistake. But I wouldn't want to do without a default ==/!=
implementation (and of course it should be defined so that an object
is only equal to itself).

In fact, the original hash() was clever enough to complain when __eq__
(or __cmp__) was overridden but __hash__ wasn't; but this got lost by
accident for new-style classes when I added a default __hash__ to the
new universal base class (object). But I think the original default
hash() isn't particularly useful, so I think it's better to just not
be hashable unless __hash__ is defined explicitly.

> 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.

This argues against the inequalities (<, <=, >, >=) and I agree.

> 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.

I don't like that final suggestion. Before you know it, a meme
develops telling newbies that all classes should inherit from that
"optional" base class, and then later it's impossible to remove it
because you can't tell whether it's actually needed or not.

> 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.

Agreed.

> Lets plan to stop guessing how to do hash and comparison.
>
> Explicit is better than implicit. :)

Except that I really don't think that there's anything wrong with a
default __eq__ that uses object identity. As Martin pointed out, it's
just too weird that an object wouldn't be considered equal to itself.
It's the default __hash__ and __cmp__ that mess things up.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)