Python 3.0 - is this true?

[Terry Reedy]

Kay Schluehr wrote:
> On 9 Nov., 05:04, Terry Reedy <tjre... at udel.edu> 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.