Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:

This will make the docs confusing and create an uncertainty for a user: if they 
define __eq__, do they, can they, or should they define __ne__.  

Also, it feels weird to have lists of five rich comparison methods rather than 
all six.

Tthe current docs better communicate which methods you need to supply and which 
methods get given to you for free.   Note, there is a dependency.  The 
object.__ne__ method depends on __eq__, so you don't get a useful __ne__ until 
and __eq__ is defined.  The meaning of __ne__ does in fact get changed by these 
classes.

So, while this doc edit is pedantically correct, it makes the documentation 
less useable than before.  I vote for leaving it as-is.

----------
nosy: +rhettinger

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41400>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to