Message192709
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. |
|
Date |
User |
Action |
Args |
2013-07-09 01:33:55 | ncoghlan | set | recipients:
+ ncoghlan, rhettinger, eric.araujo, lregebro, francescor, catalin.iacob, python-dev, javawizard, Jim.Jewett, codemiller |
2013-07-09 01:33:55 | ncoghlan | set | messageid: <1373333635.45.0.713751824008.issue10042@psf.upfronthosting.co.za> |
2013-07-09 01:33:55 | ncoghlan | link | issue10042 messages |
2013-07-09 01:33:54 | ncoghlan | create | |
|