This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rhettinger
Recipients barry, docs@python, maxking, r.david.murray, rhettinger, serhiy.storchaka
Date 2020-07-26.17:01:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1595782901.62.0.296590233445.issue41400@roundup.psfhosted.org>
In-reply-to
Content
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.
History
Date User Action Args
2020-07-26 17:01:41rhettingersetrecipients: + rhettinger, barry, r.david.murray, docs@python, serhiy.storchaka, maxking
2020-07-26 17:01:41rhettingersetmessageid: <1595782901.62.0.296590233445.issue41400@roundup.psfhosted.org>
2020-07-26 17:01:41rhettingerlinkissue41400 messages
2020-07-26 17:01:41rhettingercreate