Python 3.0 - is this true?

P

Peter Otten

walterbyrd said:
I have read that in Python 3.0, the following will raise an exception:

Will that raise an exception?
Yes.
Traceback (most recent call last):
And, if so, why are they doing this? How
is this helpful? Is this new "enhancement" Pythonic?

Is 1 > "A"? Is ord("B") > "A", "11" > 10?
What happens for sorted([datetime.time(), "now"])?

As the Zen puts it:

"In the face of ambiguity, refuse the temptation to guess."

So yes, I think this is an enhancement, and a pythonic one.

Peter
 
A

Arnaud Delobelle

walterbyrd said:
I have read that in Python 3.0, the following will raise an exception:

Will that raise an exception?

Yes. In fact, plenty of objects of different types aren't comparable
anymore.
And, if so, why are they doing this?

How is it helpful to be able to sort things which have no natural order?
How is this helpful?

It goes well with duck typing. It lets you know when you things happen
that you don't mean to happen.
Is this new "enhancement" Pythonic?

By definition!
 
S

Steven D'Aprano

How is it helpful to be able to sort things which have no natural order?

Assuming you need to sort arbitrary types, then you have to choose an
order, even if it is arbitrary, so long as it's consistent.

I agree that Python shouldn't try to guess how to order incomparable
types, nor how to order unorderable types, but I'm pretty sure that by
using the key argument to sort you can specify your own ordering. I don't
have Python 3 installed here, but some variation on this will probably
work:
alist = [2+3j, -4+5j, 8+2j, 1-7j, 6]
sorted(alist, key=str)
[(-4+5j), (1-7j), (2+3j), (8+2j), 6]



Define your own ordering if you need to sort incomparable types.
 
W

walterbyrd

Define your own ordering if you need to sort incomparable types.

If you starting new, I suppose you can always work around this new
enhancement. But, couldn't this cause a lot of backward compatibility
issues?

Also, I thought that part of the python philosophy was to allow any
sort of object in a list, and to allow the same methods to work with
whatever was in list.
 
W

walterbyrd

It goes well with duck typing.  It lets you know when you things happen
that you don't mean to happen.

But doesn't that also make the language less flexible?

For example, if I used C, I would never have to worry about assigning
a float to an integer variable. The language will not allow it. I
thought that python's flexibility, in regard to that sort of thing,
was supposed to be one of python's great strengths.

Would it be better if python lists only accepted one type of data?
Wouldn't that even go further to let you know when things happen, that
you don't mean to happen?
 
T

Terry Reedy

Steven said:
How is it helpful to be able to sort things which have no natural order?

Assuming you need to sort arbitrary types, then you have to choose an
order, even if it is arbitrary, so long as it's consistent.

I agree that Python shouldn't try to guess how to order incomparable
types, nor how to order unorderable types, but I'm pretty sure that by
using the key argument to sort you can specify your own ordering. I don't
have Python 3 installed here, but some variation on this will probably
work:
alist = [2+3j, -4+5j, 8+2j, 1-7j, 6]
sorted(alist, key=str)
[(-4+5j), (1-7j), (2+3j), (8+2j), 6]
Define your own ordering if you need to sort incomparable types.

Yes, key= lets you sort anything anyway you want.
>>> l=[1, '2', 3j]
>>> sorted(l, key = str) [1, '2', 3j]
>>> sorted(l, key = id)
['2', 3j, 1]
 
T

Terry Reedy

walterbyrd wrote:

Guido and the developers changed the behavior of order comparisons, and
hence of sorts, because they agreed, on the basis of person-decades of
experience, with no dissent that I know of, that the new behavior would
be better.

Have you written any Python code where you really wanted the old,
unpredictable behavior?
Would it be better if python lists only accepted one type of data?

Take a look at the array module.
 
K

Kay Schluehr

Have you written any Python code where you really wanted the old,
unpredictable behavior?

Sure:

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 ).
 
S

Steven D'Aprano

If you starting new, I suppose you can always work around this new
enhancement. But, couldn't this cause a lot of backward compatibility
issues?

Which is why the change has only been introduced into Python 3, and not
Python 2.x.

Also, I thought that part of the python philosophy was to allow any sort
of object in a list, and to allow the same methods to work with whatever
was in list.

You wouldn't expect this to work would you?

sum( [1, 2, None, "a string", {'x': 5}, []] )

You can only sum objects which are compatible. You can only sort objects
which define an order: you can't sort lists containing complex numbers
because "greater than" and "less than" aren't defined for complex
numbers, and in Python 3 you will no longer be able to order mixed
objects unless they are intrinsically comparable (e.g. floats and ints),
unless you define your own order.
 
K

Kay Schluehr

that same thing could be done with a multiset type, which would also
have better performance(O(n) vs. O(nlogn)).

I guess building a multiset is a little more expensive than just O(n).
It is rather like building a dict from a list which is O(k*n) with a
constant but small factor k. The comparison is of the same order. To
enable the same behavior as the applied sorted() a multiset must
permit unhashable elements. dicts don't do the job.
 
S

Steven D'Aprano

Sure:

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 ).

How often do you care about equality ignoring order for lists containing
arbitrary, heterogeneous types?

In any case, the above doesn't work now, since either L1 or L2 might
contain complex numbers. The sorted() trick only works because you're
making an assumption about the kinds of things in the lists. If you want
to be completely general, the above solution isn't guaranteed to work.

If you're prepared to assume hashability, then the obvious Multiset
solution is probably better even than the above. If you want complete
generality, you can't even assume that items in the list can be ordered
at all, so you need something like this:


def collate_and_sort(L):
D = {}
for item in L:
t = type(item)
x = D.setdefault(t, [])
x.append(item)
for x in D.values():
try:
x.sort()
except TypeError:
try:
x.sort(key=str)
except TypeError:
x.sort(key=id)
return D


def unordered_equals(L1, L2):
if len(L1) != len(L2):
return False
try:
return sorted(L1) == sorted(L2)
except TypeError:
return collate_and_sort(L1) == collate_and_sort(L2)


But note that even this solution isn't perfect, since it will fail to do
the right thing for L1=[1, {}, 2] and L2=[1, {}, 2.0]. Here is a way to
solve the problem assuming only that the items support equality:

def unordered_equals2(L1, L2):
if len(L1) != len(L2):
return False
for item in L1:
if L1.count(item) != L2.count(item):
return False
return True
 
K

Kay Schluehr

How often do you care about equality ignoring order for lists containing
arbitrary, heterogeneous types?

A few times. Why do you care, Steven?
In any case, the above doesn't work now, since either L1 or L2 might
contain complex numbers.
The sorted() trick only works because you're
making an assumption about the kinds of things in the lists. If you want
to be completely general, the above solution isn't guaranteed to work.

You are right. I never used complex numbers in Python so problems were
not visible. Otherwise the following comp function in Python 2.X does
the job:

def comp(x1, x2):
try:
if x1<x2:
return -1
else:
return 1
except TypeError:
if str(x1)<str(x2):
return -1
else:
return 1

Not sure how to transform it into a search key that is efficient and
reliable.

[...]
Here is a way to
solve the problem assuming only that the items support equality:

def unordered_equals2(L1, L2):
if len(L1) != len(L2):
return False
for item in L1:
if L1.count(item) != L2.count(item):
return False
return True

Which is O(n**2) as you might have noted.
 
S

Steven D'Aprano

A few times. Why do you care, Steven?

I'm a very caring kind of guy.

In any case, the above doesn't work now, since either L1 or L2 might
contain complex numbers.
The sorted() trick only works because you're making an assumption about
the kinds of things in the lists. If you want to be completely general,
the above solution isn't guaranteed to work.

You are right. I never used complex numbers in Python so problems were
not visible. Otherwise the following comp function in Python 2.X does
the job: [...]
Not sure how to transform it into a search key that is efficient and
reliable.

Yes, that's a general problem. It's not always easy to convert a sort
comparison function into a key-based sort. I know that 99% of the time
key is the right way to do custom sorts, but what about the other 1%?

[...]
Here is a way to
solve the problem assuming only that the items support equality:

def unordered_equals2(L1, L2):
if len(L1) != len(L2):
return False
for item in L1:
if L1.count(item) != L2.count(item):
return False
return True

Which is O(n**2) as you might have noted.

Yes, I did notice. If you can't assume even ordering, then you need to do
a lot more work.
 
A

Arnaud Delobelle

Kay Schluehr said:
On 9 Nov., 07:06, Steven D'Aprano <st...@REMOVE-THIS- [...]
In any case, the above doesn't work now, since either L1 or L2 might
contain complex numbers.
The sorted() trick only works because you're
making an assumption about the kinds of things in the lists. If you want
to be completely general, the above solution isn't guaranteed to work.

You are right. I never used complex numbers in Python so problems were
not visible. Otherwise the following comp function in Python 2.X does
the job:

def comp(x1, x2):
try:
if x1<x2:
return -1
else:
return 1
except TypeError:
if str(x1)<str(x2):
return -1
else:
return 1

Sadly it fails on transitivity:
-1
 
R

Rhamphoryncus

I guess building a multiset is a little more expensive than just O(n).
It is rather like building a dict from a list which is O(k*n) with a
constant but small factor k. The comparison is of the same order. To
enable the same behavior as the applied sorted() a multiset must
permit unhashable elements. dicts don't do the job.

Although it has a runtime of k*n, it is still O(n). big-O notation
ignores constant factors, dealing only with scalability.
 
S

Stefan Behnel

Kay said:
A few times. Why do you care, Steven?

"I miss this feature" is an unqualified statement, just like "I'll miss George
W. Bush". That does not necessarily imply that I want him back in the position
that the had for the last eight years. It might just mean that it was fun to
see him on telly (although I bet his entertainment show was more expensive
than the average Marx-Brothers sketch).

Stefan
 
K

Kay Schluehr

Although it has a runtime of k*n, it is still O(n).  big-O notation
ignores constant factors, dealing only with scalability.

You are right. I remembered this short after my posting was sent.
 
R

Roy Smith

Terry Reedy said:
Yes, key= lets you sort anything anyway you want.
l=[1, '2', 3j]
sorted(l, key = str)
[1, '2', 3j]

The problem here is that str() is degenerate, i.e. a != b does not imply
str(a) != str(b).
['2', 3j, 1]

And of course, this has to opposite problem, a == b does not imply id(a) ==
id(b). Whether either of these "problems" is really a problem obviously
depends on what you're trying to do.

In 3.0, can you still order types? In 2.x, you can do:
False

If this still works in 3.0, then you can easily do something like:

def total_order(o1, o2):
"Compare any two objects of arbitrary types"
try:
return o1 <= o2
except UncomparableTypesError: # whatever the right name is
return type(o1) <= type(o2)

and get the same effect as you had in 2.x.
 
D

Diez B. Roggisch

Also, I thought that part of the python philosophy was to allow any
sort of object in a list, and to allow the same methods to work with
whatever was in list.

Not really. When the usual argument about the existence (and
justification) of lists & tuples comes along, one common distinction is
that

- tuples contain arbitrary object of varying types, so they are kind
of "records"
- lists should contain uniform objects.

None of this is enforced, but it's good customs to do so & to put it
frankly: if I came along a piece of code that created a list like the
one you presented, I'd say it's a code-smell.

Diez
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top