On 12/6/10 11:16 AM, TomF wrote:
On 2010-12-06 09:04:00 -0800, Peter Otten said:
This change would break a lot of code, so it could not be made within the
2.x series. However:
Python 3.1.1+ (r311:74480, Nov 2 2009, 15:45:00)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
"4" < 7
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: str() < int()
Thanks. I was hoping there was something I could do for 2.x but I suppose this
will have to do.
But I'm mystified by your statement, "this change would break a lot of code".
Given that the semantics are virtually random, how could code depend on this?
There are cases where you don't particularly care *what* order is given as long
as it is consistent. Let's say you want to make sure that two lists have the
same contents (which may mix types), but you don't care about the order. You
could just sort each list and then compare the sorted lists. Before sets were
added to the language, this was a fairly common approach.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
