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 ncoghlan
Recipients Jim.Jewett, catalin.iacob, codemiller, eric.araujo, francescor, javawizard, lregebro, ncoghlan, python-dev, rhettinger
Date 2013-07-09.01:33:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1373333635.45.0.713751824008.issue10042@psf.upfronthosting.co.za>
In-reply-to
Content
OK, I had misunderstood the way Jim's code works (it still coerces a "False" result for __eq__ into NotImplemented if the ordered comparison returns NotImplemented).

However, I spent some more time tinkering with it today (see
https://bitbucket.org/ncoghlan/misc/src/856bd105e5e43cb96ebaa2d250c3c801da571953/tinkering/comparisons.py?at=default ) which shows that my version (which ignores __eq__ entirely if the ordered comparison returns NotImplemented) is consistent with the current behaviour, while accepting a "True" return from __eq__ in that case (as Jim's version does) may result in some existing TypeError results becoming "True" comparison results instead.

Since this is such an incredibly niche edge case (the ordered comparison has to return NotImplemented while __eq__ returns True), I remaining consistent with the existing behaviour is the most important consideration. We'll add a test case to ensure this remains consistent, though.

The other code clarification changes look reasonable though - Katie plans to incorporate several of those.
History
Date User Action Args
2013-07-09 01:33:55ncoghlansetrecipients: + ncoghlan, rhettinger, eric.araujo, lregebro, francescor, catalin.iacob, python-dev, javawizard, Jim.Jewett, codemiller
2013-07-09 01:33:55ncoghlansetmessageid: <1373333635.45.0.713751824008.issue10042@psf.upfronthosting.co.za>
2013-07-09 01:33:55ncoghlanlinkissue10042 messages
2013-07-09 01:33:54ncoghlancreate