Mailing List Archive: Python: Python

confusing doc: mutable and hashable

Index | Next | Previous | View Threaded

laymanzheng at gmail

Apr 28, 2012, 11:09 AM

Post #1 of 10 (436 views)
Permalink

confusing doc: mutable and hashable

I'm just learning Python. The python doc about mutable and hashable is confusing to me.

In my understanding, there is no directly relation between mutable and hashable in Python. Any class with __hash__ function is "hashable".

According the wiki: http://en.wikipedia.org/wiki/Immutable_object

In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.[1] This is in contrast to a mutable object, which can be modified after it is created.

We surely can define __hash__ function in user-define class and the instance of that class can be changed thus mutable.

But following statement seems correct in practice but not technically. Any comments on this?

Thanks,
Andy

------------------------
http://docs.python.org/py3k/library/stdtypes.html#set-types-set-frozenset:
Since it is mutable, it has no hash value and cannot be used as either a dictionary key or as an element of another set.
------------------------
--
http://mail.python.org/mailman/listinfo/python-list

mwilson at the-wire

Apr 28, 2012, 11:27 AM

Post #2 of 10 (415 views)
Permalink

Re: confusing doc: mutable and hashable [In reply to]

laymanzheng [at] gmail wrote:

> I'm just learning Python. The python doc about mutable and hashable is
> confusing to me.
>
> In my understanding, there is no directly relation between mutable and
> hashable in Python. Any class with __hash__ function is "hashable".
>
> According the wiki: http://en.wikipedia.org/wiki/Immutable_object
>
> In object-oriented and functional programming, an immutable object is an
> object whose state cannot be modified after it is created.[1] This is in
> contrast to a mutable object, which can be modified after it is created.
>
> We surely can define __hash__ function in user-define class and the
> instance of that class can be changed thus mutable.
>
> But following statement seems correct in practice but not technically. Any
> comments on this?

Wikipedia has it right. Mutable objects are objects where significant
attributes of the object can change value over the lifetime of the object.
This is useful for data sharing. If, for example, one part of your program
knows an object by the name `a`, and another part knows the same object as
`b` (or if they can access the object in any other distinct ways), they can
communicate by changing values of attributes of the shared object.

In practice, hashable means that the hashable object can be used as a key in
a dict. Looking up an item in a dict means that 1) the hash of the lookup
key has to match the hash of the stored key, and 2) the lookup key has to be
equal to the stored key according to the `==` operator. These requirements
are easy to meet if the keys are immutable. Otherwise for classes you
create, you can (if you're careful) create __hash__ and __eq__ methods to
meet the requirements, even if significant attributes of your instances can
change their values.

Mel.

--
http://mail.python.org/mailman/listinfo/python-list

clp2 at rebertia

Apr 28, 2012, 11:35 AM

Post #3 of 10 (416 views)
Permalink

Re: confusing doc: mutable and hashable [In reply to]

On Sat, Apr 28, 2012 at 11:09 AM, <laymanzheng [at] gmail> wrote:
> I'm just learning Python. The python doc about mutable and hashable is confusing to me.
>
> In my understanding, there is no directly relation between mutable and hashable in Python. Any class with __hash__ function is "hashable".
>
> According the wiki: http://en.wikipedia.org/wiki/Immutable_object
>
> In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.[1] This is in contrast to a mutable object, which can be modified after it is created.
>
> We surely can define __hash__ function in user-define class and the instance of that class can be changed thus mutable.
>
> But following statement seems correct in practice but not technically. Any comments on this?

Correct. Pedantically, you can define __hash__() on mutable objects;
it's just not very useful or sensible, so people generally don't. As
http://docs.python.org/reference/datamodel.html#object.__hash__ states
[emphasis added]:

"If a class defines *mutable* objects and implements a __cmp__() or
__eq__() method, it *should not* implement __hash__(), since hashable
collection implementations require that a object’s hash value is
immutable (if the object’s hash value changes, it will be in the wrong
hash bucket)."

> ------------------------
> http://docs.python.org/py3k/library/stdtypes.html#set-types-set-frozenset:
> Since it is mutable, it has no hash value and cannot be used as either a dictionary key or as an element of another set.
> ------------------------

Cheers,
Chris
--
http://mail.python.org/mailman/listinfo/python-list

kiuhnm03.4t.yahoo.it at mail

Apr 28, 2012, 2:56 PM

Post #4 of 10 (411 views)
Permalink

Re: confusing doc: mutable and hashable [In reply to]

On 4/28/2012 20:09, laymanzheng [at] gmail wrote:
> I'm just learning Python. The python doc about mutable and hashable is confusing to me.
>
> In my understanding, there is no directly relation between mutable and hashable in Python. Any class with __hash__ function is "hashable".
>
> According the wiki: http://en.wikipedia.org/wiki/Immutable_object
>
> In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.[1] This is in contrast to a mutable object, which can be modified after it is created.
>
> We surely can define __hash__ function in user-define class and the instance of that class can be changed thus mutable.
>
> But following statement seems correct in practice but not technically. Any comments on this?
>
> Thanks,
> Andy
>
> ------------------------
> http://docs.python.org/py3k/library/stdtypes.html#set-types-set-frozenset:
> Since it is mutable, it has no hash value and cannot be used as either a dictionary key or as an element of another set.
> ------------------------

Yes, you're right. Being mutable and hashable are orthogonal properties.
The implication
mutable => non hashable
is just a design choice.

The reason for such a choice is the following. If a key-element pair K:X
is added to a container C and then K is changed by some external Python
code without letting C know of this change, C may become inconsistent.
Some containers (e.g. set) assume that K=X and just take X. Modifying X
is equivalent to modifying K in the example above.
These kinds of problems are avoided if mutable objects can't be keys.
Some containers require that keys be hashable, but since, by design,
mutable objects can't be keys, there's no reason for them to be hashable
either.

Kiuhnm
--
http://mail.python.org/mailman/listinfo/python-list

lamialily at cleverpun

Apr 28, 2012, 3:30 PM

Post #5 of 10 (412 views)
Permalink

Re: confusing doc: mutable and hashable [In reply to]

>Yes, you're right. Being mutable and hashable are orthogonal properties.
>The implication
> mutable => non hashable
>is just a design choice.
>
>The reason for such a choice is the following. If a key-element pair K:X
>is added to a container C and then K is changed by some external Python
>code without letting C know of this change, C may become inconsistent.
>Some containers (e.g. set) assume that K=X and just take X. Modifying X
>is equivalent to modifying K in the example above.
>These kinds of problems are avoided if mutable objects can't be keys.
>Some containers require that keys be hashable, but since, by design,
>mutable objects can't be keys, there's no reason for them to be hashable
>either.
>
>Kiuhnm

Well, if worst comes to worst and you wind up in a programming
situation where you needed to make a mutable object as a hash entry,
it's still possible to subclass the object type and have __hash__()
return the object's ID instead, right?

I can only think of a few edge cases where that could even possibly be
required though, such as membership testing for something and having a
callback associated with each set of members...

~Temia
--
When on earth, do as the earthlings do.
--
http://mail.python.org/mailman/listinfo/python-list

python at mrabarnett

Apr 28, 2012, 4:36 PM

Post #6 of 10 (409 views)
Permalink

Re: confusing doc: mutable and hashable [In reply to]

On 28/04/2012 23:30, Temia Eszteri wrote:
>>Yes, you're right. Being mutable and hashable are orthogonal properties.
>>The implication
>> mutable => non hashable
>>is just a design choice.
>>
>>The reason for such a choice is the following. If a key-element pair K:X
>>is added to a container C and then K is changed by some external Python
>>code without letting C know of this change, C may become inconsistent.
>>Some containers (e.g. set) assume that K=X and just take X. Modifying X
>>is equivalent to modifying K in the example above.
>>These kinds of problems are avoided if mutable objects can't be keys.
>>Some containers require that keys be hashable, but since, by design,
>>mutable objects can't be keys, there's no reason for them to be hashable
>>either.
>>
>>Kiuhnm
>
> Well, if worst comes to worst and you wind up in a programming
> situation where you needed to make a mutable object as a hash entry,
> it's still possible to subclass the object type and have __hash__()
> return the object's ID instead, right?
>
> I can only think of a few edge cases where that could even possibly be
> required though, such as membership testing for something and having a
> callback associated with each set of members...
>
If objects x and y of the same class are mutable and you want them to
have the same hash if x == y then having __hash__() return the object's
ID is not what you want.
--
http://mail.python.org/mailman/listinfo/python-list

tjreedy at udel

Apr 28, 2012, 7:06 PM

Post #7 of 10 (409 views)
Permalink

Re: confusing doc: mutable and hashable [In reply to]

On 4/28/2012 2:09 PM, laymanzheng [at] gmail wrote:

> In my understanding, there is no directly relation between mutable
> and hashable in Python. Any class with __hash__ function is
> "hashable".
>
> According the wiki: http://en.wikipedia.org/wiki/Immutable_object
>
> In object-oriented and functional programming, an immutable object is
> an object whose state cannot be modified after it is created.[1] This
> is in contrast to a mutable object, which can be modified after it is
> created.
>
> We surely can define __hash__ function in user-define class and the
> instance of that class can be changed thus mutable.

The default hash is based on the immutable value of an object. If you
base a custom hash on values that do change, it is not useful as a dict key.

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

arnodel at gmail

Apr 28, 2012, 11:40 PM

Post #8 of 10 (412 views)
Permalink

Re: confusing doc: mutable and hashable [In reply to]

(sent from my phone)
On Apr 28, 2012 7:36 PM, "Chris Rebert" <clp2 [at] rebertia> wrote:
> Correct. Pedantically, you can define __hash__() on mutable objects;
> it's just not very useful or sensible, so people generally don't.

I find it's fine to define __hash__ on mutable objects as long as __eq__
only relies on immutable state (and then so should __hash__ of course). A
typical example would be an object that does some caching.

--
Arnaud

research at johnohagan

Apr 29, 2012, 12:57 AM

Post #9 of 10 (412 views)
Permalink

Re: confusing doc: mutable and hashable [In reply to]

On Sat, 28 Apr 2012 11:35:12 -0700
Chris Rebert <clp2 [at] rebertia> wrote:

[...]
> Correct. Pedantically, you can define __hash__() on mutable objects;
> it's just not very useful or sensible, so people generally don't. As
> http://docs.python.org/reference/datamodel.html#object.__hash__ states
> [emphasis added]:
>
> "If a class defines *mutable* objects and implements a __cmp__() or
> __eq__() method, it *should not* implement __hash__(), since hashable
> collection implementations require that a object’s hash value is
> immutable (if the object’s hash value changes, it will be in the wrong
> hash bucket)."
[...]

How do function objects fit into this scheme? They have __hash__, __eq__, seem
to work as dict keys and are mutable. Is it because their hash value doesn't
change? Under what circumstances does an object's hash value change?
--
John

--
http://mail.python.org/mailman/listinfo/python-list

tjreedy at udel

Apr 29, 2012, 3:09 AM

Post #10 of 10 (412 views)
Permalink

Re: confusing doc: mutable and hashable [In reply to]

On 4/29/2012 3:57 AM, John O'Hagan wrote:

> How do function objects fit into this scheme? They have __hash__, __eq__, seem
> to work as dict keys and are mutable. Is it because their hash value doesn't
> change?

I suspect functions use the default equality and hash based on id, which
does not change.

> Under what circumstances does an object's hash value change?

When someone has written a buggy .__hash__ method. Or perhaps if someone
is making a non-standard, non-dict use of hash().

--
Terry Jan Reedy

--
http://mail.python.org/mailman/listinfo/python-list

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads