Brett Cannon wrote: > So +0 on your specific improvment and +1 for trying to think about > newbies when writing exception messages. The __eq__/__hash__ messages are somewhat arcane because the problem they're describing is somewhat arcane. Michael's suggested improvement also isn't quite right (and I believe indicates that we're susceptible to issuing false alarms in this case). You really only need to override __hash__ if you want your object to remain hashable, but we currently issue the warning for any object that defines __eq__ without defining __hash__. Perhaps the implementation of that warning should be improved so that it is only issued if the default __hash__ implementation is actually invoked on an affected object? (the downside is that depending on the implementation technique the extra checks may slow down hashing under "python -3", but I guess that kind of the undesirable impact is the reason we have all those warnings switched off by default) Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
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