[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