[Python-Dev] PyObject_RichCompareBool identity shortcut
Glenn Linderman
v+python at g.nevcal.com
Fri Apr 29 02:24:35 CEST 2011
On 4/28/2011 4:40 PM, Nick Coghlan wrote:
> Hmm, true. And things like count() and index() would still be
> thoroughly broken for sequences. OK, so scratch that idea - there's
> simply no sane way to handle such objects without using an
> identity-based container that ignores equality definitions altogether.
And the problem with that is that not all values are interned, to share
a single identity per value, correct?
On the other hand, proliferation of float objects containing NaN
"works", thus so would proliferation of non-float objects of the same
value... but "works" would have a different meaning when there could be
multiple identities of 6,981,433 in the same set.
But this does bring up an interesting enough point to cause me to rejoin
the conversation:
Would it be reasonable to implement 3 types of containers:
1) using __eq__ (would not use identity comparison optimization)
2) using is (the case you describe above)
3) the status quo: is or __eq__
The first two would require an explicit constructor call because the
syntax would be retained for case 3 for backward compatibility.
Heavy users of NaN and other similar values might find case 1 useful,
although they would need to be careful with mappings and sets.
Heavy users of NumPy and other similar structures might find case 2 useful.
Offering the choice, and documenting the alternatives may make a lot
more programmers choose the proper comparison operations, and less
likely to overlook or pooh-pooh the issue with the thought that it won't
happen to their program anyway...
More information about the Python-Dev
mailing list