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...
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
