Kay Schluehr wrote:

> On 9 Nov., 05:04, Terry Reedy <(E-Mail Removed)> 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.