Guido van Rossum <guido@python.org> writes:

...

This code

class X: def __cmp__(self, other): return 1

c1 = X()

d = {} d[c1] = None

raises a TypeError, unhashable type, since the class does not define a __hash__ method.

This error is no longer raised when X derives from object. Bug (or feature)?

It's something in between. :-(

I've been struggling with this since 2.2 and not found a good solution. Built-in mutable types like list and dict deal with this by having an explicit tp_hash slot that raises an exception.

Why doesn't the default implementation raise a TypeError (or be NULL), and the immutable types override this?

Can you add a SF entry and assign it to me? Any insight you might have in the matter would be appreciated.

Sure. Thomas

On maandag, dec 30, 2002, at 17:30 Europe/Amsterdam, Guido van Rossum wrote:

The default implementation of __hash__ must match the default implementation of __cmp__ (and rich comparisons, __eq__ etc.). So the default implementation cannot raise an exception, because objects are defined to be immutable by default. (Maybe this was a mistake, but it's not so easy to change without causing backwards incompatibilities.)

Is it an option to enforce that these methods are overridden together, then? I.e. if you override any of them you must override all of them, otherwise you get a warning? -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

On maandag, dec 30, 2002, at 23:26 Europe/Amsterdam, Guido van Rossum wrote:

...

On maandag, dec 30, 2002, at 17:30 Europe/Amsterdam, Guido van Rossum wrote:

...

The default implementation of __hash__ must match the default implementation of __cmp__ (and rich comparisons, __eq__ etc.). So the default implementation cannot raise an exception, because objects are defined to be immutable by default. (Maybe this was a mistake, but it's not so easy to change without causing backwards incompatibilities.)

Is it an option to enforce that these methods are overridden together, then? I.e. if you override any of them you must override all of them, otherwise you get a warning?

That's nice, but I'm not sure I can see right away how to do the warning.

I assume there's some equivalent of PyType_Ready, or not? Wouldn't that be the right spot?

Also, there are cases where a base class defines both properly, and then a subclass overrides one but not the other. Is that worth a warning or not? That depends on how they change it!

It's easy enough to add dummy methods that just call the same method in the base class. But still: this whole warning idea could be overkill, that's for you to decide:-) -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

Guido van Rossum <guido@python.org> writes:

...

This code

class X: def __cmp__(self, other): return 1

c1 = X()

d = {} d[c1] = None

raises a TypeError, unhashable type, since the class does not define a __hash__ method.

This error is no longer raised when X derives from object. Bug (or feature)?

It's something in between. :-(

I've been struggling with this since 2.2 and not found a good solution. Built-in mutable types like list and dict deal with this by having an explicit tp_hash slot that raises an exception.

Why doesn't the default implementation raise a TypeError (or be NULL), and the immutable types override this?

Can you add a SF entry and assign it to me? Any insight you might have in the matter would be appreciated.

Sure. Thomas

On maandag, dec 30, 2002, at 17:30 Europe/Amsterdam, Guido van Rossum wrote:

The default implementation of __hash__ must match the default implementation of __cmp__ (and rich comparisons, __eq__ etc.). So the default implementation cannot raise an exception, because objects are defined to be immutable by default. (Maybe this was a mistake, but it's not so easy to change without causing backwards incompatibilities.)

Is it an option to enforce that these methods are overridden together, then? I.e. if you override any of them you must override all of them, otherwise you get a warning? -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -

On maandag, dec 30, 2002, at 23:26 Europe/Amsterdam, Guido van Rossum wrote:

...

On maandag, dec 30, 2002, at 17:30 Europe/Amsterdam, Guido van Rossum wrote:

...

The default implementation of __hash__ must match the default implementation of __cmp__ (and rich comparisons, __eq__ etc.). So the default implementation cannot raise an exception, because objects are defined to be immutable by default. (Maybe this was a mistake, but it's not so easy to change without causing backwards incompatibilities.)

Is it an option to enforce that these methods are overridden together, then? I.e. if you override any of them you must override all of them, otherwise you get a warning?

That's nice, but I'm not sure I can see right away how to do the warning.

I assume there's some equivalent of PyType_Ready, or not? Wouldn't that be the right spot?

Also, there are cases where a base class defines both properly, and then a subclass overrides one but not the other. Is that worth a warning or not? That depends on how they change it!

It's easy enough to add dummy methods that just call the same method in the base class. But still: this whole warning idea could be overkill, that's for you to decide:-) -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -