Re: Documentation of __hash__

[Ethan Furman]

On 02/11/2020 02:23 AM, klau...@gmail.com wrote:

On Friday, February 7, 2020 at 4:30:23 PM UTC+1, Random832 wrote:



The purpose of this rule is to save you from having to override the default 
__hash__ with something that will only raise an exception when you do not 
intend your class to be hashable.


If I do not intend my class to be hashable, I will set __hash__ to None 
(according to the documentation).


If you define your own __eq__ method, __hash__ is automatically set to None.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: Documentation of __hash__

[klauck2]

On Friday, February 7, 2020 at 4:30:23 PM UTC+1, Random832 wrote:
> On Fri, Feb 7, 2020, at 10:14, Richard Damon wrote:
> > On 2/6/20 2:13 PM, klau...@gmail.com wrote:
> > > The default __eq__ method (object identity) is compatible with all 
> > > (reasonable) self-defined __hash__ method.
> > >
> > > Stefan
> > 
> > If __eq__ compares just the id, then the only hash you need is the 
> > default that is also the id. If you define a separate hash function, 
> > which uses some of the 'value' of the object, then presumably you intend 
> > for objects where that 'value' matches to be equal, which won't happen 
> > with the default __eq__.
> 
> I think Stefan's point is that, no matter how questionable the intent may 
> sound, any deterministic __hash__ doesn't technically violate the hash/eq 
> relationship with the default __eq__, because hash(x) will still be equal to 
> hash(x). Only defining __eq__ can create the problem where x == y but hash(x) 
> != hash(y).

Yes, this is my question.

> 
> The purpose of this rule is to save you from having to override the default 
> __hash__ with something that will only raise an exception when you do not 
> intend your class to be hashable.

If I do not intend my class to be hashable, I will set __hash__ to None 
(according to the documentation).


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

Re: Documentation of __hash__

[Random832]

On Fri, Feb 7, 2020, at 10:14, Richard Damon wrote:
> On 2/6/20 2:13 PM, klau...@gmail.com wrote:
> > The default __eq__ method (object identity) is compatible with all 
> > (reasonable) self-defined __hash__ method.
> >
> > Stefan
> 
> If __eq__ compares just the id, then the only hash you need is the 
> default that is also the id. If you define a separate hash function, 
> which uses some of the 'value' of the object, then presumably you intend 
> for objects where that 'value' matches to be equal, which won't happen 
> with the default __eq__.

I think Stefan's point is that, no matter how questionable the intent may 
sound, any deterministic __hash__ doesn't technically violate the hash/eq 
relationship with the default __eq__, because hash(x) will still be equal to 
hash(x). Only defining __eq__ can create the problem where x == y but hash(x) 
!= hash(y).

The purpose of this rule is to save you from having to override the default 
__hash__ with something that will only raise an exception when you do not 
intend your class to be hashable.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Documentation of __hash__

[Richard Damon]

On 2/6/20 2:13 PM, klau...@gmail.com wrote:

The default __eq__ method (object identity) is compatible with all (reasonable) 
self-defined __hash__ method.

Stefan


If __eq__ compares just the id, then the only hash you need is the 
default that is also the id. If you define a separate hash function, 
which uses some of the 'value' of the object, then presumably you intend 
for objects where that 'value' matches to be equal, which won't happen 
with the default __eq__.


--
Richard Damon

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

Re: Documentation of __hash__

[klauck2]

The default __eq__ method (object identity) is compatible with all (reasonable) 
self-defined __hash__ method.

Stefan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Documentation of __hash__

[Christian Gollwitzer]

Am 05.02.20 um 20:55 schrieb klau...@gmail.com:


If not, why should a class not define __hash__, if it does not define __eq__?


Hashes are not unique. When you insert or look up something in a 
hashtable, the hash is computed and used as the index into the table. 
Because the hash is not necessarily unique, if hash(a)=hash(b), it can 
still be that a=/= b. Therefore, in a second step, a is compared to b if 
the hashes match.


Therefore, you need a comparison operator which is compatible with the 
hash function, i.e. if a==b, then hash(a) must be equal to hash(b).


Christian

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

Re: Documentation of __hash__

[klauck2]

On Wednesday, February 5, 2020 at 7:41:13 PM UTC+1, Dieter Maurer wrote:
> Stefan Halfpap wrote at 2020-2-5 14:57 +0100:
> >I do not understand the following statement from the python (2 and 3) 
> >documentation regarding __hash__ and __eq__ methods:
> >"If a class does not define an __eq__() 
> > method it 
> >should not define a __hash__() 
> > 
> >operation either;”
> >(see https://docs.python.org/3/reference/datamodel.html#object.__hash__ 
> > )
> >
> >I thought it relates to the second part (“if it defines __eq__() 
> > but not 
> >__hash__() 
> >, its 
> >instances will not be usable as items in hashable collections”), which is 
> >totally clear to me.
> >But then the implication should be the other way around.
> 
> "if not A then not B" is equivalent to "if B then A".
> 
> In your case: "__eq__ not defined, then __hash__ not defined"
> is equivalent to "__hash__ definied requires __eq__ defined".

You are right.
This is what the (first part of the) documentation says,
but I do not know why.

I thought it should be:
"if __hash__ is not defined, then __eq__ should not be defined"
which is equivalent to "__eq__ defined then __hash__ should be defined" (the 
second part, which is clear to me)

If not, why should a class not define __hash__, if it does not define __eq__?



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

Re: Documentation of __hash__

[Dieter Maurer]

Stefan Halfpap wrote at 2020-2-5 14:57 +0100:
>I do not understand the following statement from the python (2 and 3) 
>documentation regarding __hash__ and __eq__ methods:
>"If a class does not define an __eq__() 
> method it 
>should not define a __hash__() 
> operation 
>either;”
>(see https://docs.python.org/3/reference/datamodel.html#object.__hash__ 
> )
>
>I thought it relates to the second part (“if it defines __eq__() 
> but not 
>__hash__() 
>, its 
>instances will not be usable as items in hashable collections”), which is 
>totally clear to me.
>But then the implication should be the other way around.

"if not A then not B" is equivalent to "if B then A".

In your case: "__eq__ not defined, then __hash__ not defined"
is equivalent to "__hash__ definied requires __eq__ defined".
-- 
https://mail.python.org/mailman/listinfo/python-list

Documentation of __hash__

[Stefan Halfpap]

Hi,

I do not understand the following statement from the python (2 and 3) 
documentation regarding __hash__ and __eq__ methods:
"If a class does not define an __eq__() 
 method it 
should not define a __hash__() 
 operation 
either;”
(see https://docs.python.org/3/reference/datamodel.html#object.__hash__ 
 )

I thought it relates to the second part (“if it defines __eq__() 
 but not 
__hash__() 
, its 
instances will not be usable as items in hashable collections”), which is 
totally clear to me.
But then the implication should be the other way around.

But what is the reason (meaning) for the statement as it is?

Best regards,
Stefan
-- 
https://mail.python.org/mailman/listinfo/python-list