Kay Schluehr wrote:
On 9 Nov., 05:04, Terry Reedy <[EMAIL PROTECTED]> wrote:
Have you written any Python code where you really wanted the old,
unpredictable behavior?
Sure:
I was asking the OP ;-)
if len(L1) == len(L2):
return sorted(L1) == sorted(L2) # check whether two lists contain
the same elements
else:
return False
It doesn't really matter here what the result of the sorts actually is
as long as the algorithm leads to the same result for all permutations
on L1 ( and L2 ).
Leaving aside the O(n) alternative for hashable items, which only
matters for 'long' lists....
If you literally mean 'the same elements', then key=id would work.
For some mixtures, such as strings and numbers, key=id will work better
than in 2.x since complex numbers can be included.
If you want to duplicate 2.x behavior, which does *not* work for all
types...
def py2key(item): return (str(type(item)), item)
Guido is aware that universal compare was occasionally useful, but
decided that it also caused problems. So he broke universal compare
when he introduced complex numbers without arbitrary comparisons.
Decimal numbers are even worse. So anyone who objects to the change in
3.0 *should* have objected when complex numbers were introduced.
--
http://mail.python.org/mailman/listinfo/python-list
