[Python-Dev] bool does not want to be subclassed?

[Tim Peters]

[François Pinard]
>> However, all types derive from object, and object has `__hash__'.
>> Consequently, I would be tempted to think that under the new system,
>> everything deriving from object is immutable by construction, unless
>> tricks are used against it.

That object has __hash__ now is considered to be a bug:

    "New style classes and __hash__"
    http://www.python.org/sf/660098

[Martin v. Löwis]
> You are also misinterpreting "defines a hash function". Any object
> is hashable,

That's not so; e.g.,

>>> hash([])
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: list objects are unhashable
>>>

or

>>> class C:
...     def __cmp__(a, b): return 0
>>> hash(C())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unhashable instance
>>>

That changing the last to use a new-style class:

>>> class C(object):
...    def __cmp__(a, b): return 0
...
>>> hash(C())
6973584
>>>

doesn't complain is one of the bugs in the report referenced above.  The
docs for __hash__ still spell out the *intent*:

    If a class does not define a __cmp__() method it should not
    define a __hash__() operation either; if it defines __cmp__()
    or __eq__() but not __hash__(), its instances will not be usable
    as dictionary keys.  If a class defines mutable objects and
    implements a __cmp__() or __eq__() method, it should not implement
    __hash__(), since the dictionary implementation requires that a key's
    hash value is immutable (if the object's hash value changes, it will
    be in the wrong hash bucket)

Old-style class instances work that way, and to the extent new-style class
instances don't in 2.3, the new-style class implementation is in error.

> but, unless specifically defined, the hash function uses
> the identity of the object (in CPython, its address) to compute the
> hash; this won't change if the state changes.
>
> So you should read Guido's statement also as "it's wrong if a mutable
> object *specifically* defines a hash function".

>> What means a "mutable type" then?

It's gotten more <wink> confused.  When types and classes were distinct
beasts, types were immutable and classes were mutable, and instances of
types or classes could be mutable or immutable (depending on the type or
class they were instances of).  The word "type" has lost its crispness in
that respect.

> A mutable type is one whose instances have state that can change over
> the life of the object.

I accept that, but it's not very useful on its own.  Whether a type compares
instances via value or via identity, and whether a type's instances can be
used as dict keys, and whether a type's instances can be *sanely* used as
dict keys, and whether a type's instances are hashable, can't be predicted
just from knowing that the type's instances are mutable or immutable -- but
people think they can be <wink>.