A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-December/031475.html below:

[Python-Dev] 'unhashable type' and new style classes

[Python-Dev] 'unhashable type' and new style classesJack Jansen Jack.Jansen@oratrix.com
Tue, 31 Dec 2002 00:15:03 +0100
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 -




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4