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
