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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
