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

Reply via email to