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...