Python 3.0 - is this true? - Python

walterbyrd wrote:

> I have read that in Python 3.0, the following will raise an exception:
>
>>>> [2, 1, 'A'].sort()
>
> Will that raise an exception?

Yes.

>>> [2, 1, "a"].sort()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: str() < int()

> 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

walterbyrd <walterbyrd@iname.com> writes:

> I have read that in Python 3.0, the following will raise an exception:
>
>>>> [2, 1, 'A'].sort()
>
> 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!

--
Arnaud

On Sat, 08 Nov 2008 19:02:28 +0000, Arnaud Delobelle wrote:

>> And, if so, why are they doing this?
>
> 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.



--
Steven

On Nov 8, 7:44 pm, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.au> wrote:

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

On Nov 8, 12:02 pm, Arnaud Delobelle <arno...@googlemail.com> wrote:

> 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?

Steven D'Aprano wrote:
> On Sat, 08 Nov 2008 19:02:28 +0000, Arnaud Delobelle wrote:
>
>>> And, if so, why are they doing this?
>> 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]

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.

On 9 Nov., 05:04, Terry Reedy <tjre...@udel.edu> wrote:

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

On Nov 8, 11:36 pm, Kay Schluehr <kay.schlu...@gmx.net> wrote:
> On 9 Nov., 05:04, Terry Reedy <tjre...@udel.edu> wrote:
>
> > 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 ).

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