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

Re: How to instlal pyodbc, without pip

[dcwhatthe]

On Tuesday, February 4, 2020 at 8:53:10 PM UTC-5, Souvik Dutta wrote:
> You might use chocolatey if you like.
> 
> On Tue, 4 Feb, 2020, 11:05 pm , dcwhatthe wrote:
> 
> > Hi,
> >
> > Pip won't work on my desktop, because of the firewalls we have set up.
> >
> > I have the version from github.  Assuming my Python 3.8.1 Home Directory
> > is C:\Python, How can I install pyodbc pyodbc-master.zip?  Which folders
> > should I unzip it into?
> >
> >
> >
> > Regards,
> >
> >
> >
> >
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >

Thanks DL Neil, Terry, and Souvik,

I was able to install them manually, by going to the ..\libregrtest\ folder, 
copying the .zip there, and running it against the package, thus:

pip install --trusted-host pyodbc-master.zip

-- 
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

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__

[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

Multiprocessing, join(), and crashed processes

[Israel Brewster]

In a number of places I have constructs where I launch several processes using 
the multiprocessing library, then loop through said processes calling join() on 
each one to wait until they are all complete. In general, this works well, with 
the *apparent* exception of if something causes one of the child processes to 
crash (not throw an exception, actually crash). In that event, it appears that 
the call to join() hangs indefinitely. How can I best handle this? Should I put 
a timeout on the join, and put it in a loop, such that every 5 seconds or so it 
breaks, checks to see if the process is still actually running, and if so goes 
back and calls join again? Or is there a better option to say “wait until this 
process is done, however long that may be, unless it crashes”?
---
Israel Brewster
Software Engineer
Alaska Volcano Observatory 
Geophysical Institute - UAF 
2156 Koyukuk Drive 
Fairbanks AK 99775-7320
Work: 907-474-5172
cell:  907-328-9145

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

Re: Multiprocessing, join(), and crashed processes

[Cameron Simpson]

On 05Feb2020 15:48, Israel Brewster  wrote:
In a number of places I have constructs where I launch several 
processes using the multiprocessing library, then loop through said 
processes calling join() on each one to wait until they are all 
complete. In general, this works well, with the *apparent* exception of 
if something causes one of the child processes to crash (not throw an 
exception, actually crash). In that event, it appears that the call to 
join() hangs indefinitely. How can I best handle this? Should I put a 
timeout on the join, and put it in a loop, such that every 5 seconds or 
so it breaks, checks to see if the process is still actually running, 
and if so goes back and calls join again? Or is there a better option 
to say “wait until this process is done, however long that may be, 
unless it crashes”?


What's your platform/OS? And what does "crash" mean, precisely?

If a subprocess exits, join() should terminate.

If the subprocess _hangs_, then join will not see it exit, because it 
hasn't. And join will hang.


You'll need to define what happens when your subprocesses crash.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list