Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python 3.0 - is this true?

Reply
Thread Tools

Python 3.0 - is this true?

 
 
walterbyrd
Guest
Posts: n/a
 
      11-08-2008
I have read that in Python 3.0, the following will raise an exception:

>>> [2, 1, 'A'].sort()


Will that raise an exception? And, if so, why are they doing this? How
is this helpful? Is this new "enhancement" Pythonic?
 
Reply With Quote
 
 
 
 
Peter Otten
Guest
Posts: n/a
 
      11-08-2008
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
 
Reply With Quote
 
 
 
 
Arnaud Delobelle
Guest
Posts: n/a
 
      11-08-2008
walterbyrd <(E-Mail Removed)> 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

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-09-2008
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
 
Reply With Quote
 
walterbyrd
Guest
Posts: n/a
 
      11-09-2008
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.

 
Reply With Quote
 
walterbyrd
Guest
Posts: n/a
 
      11-09-2008
On Nov 8, 12:02*pm, Arnaud Delobelle <(E-Mail Removed)> 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?
 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      11-09-2008
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]


 
Reply With Quote
 
Terry Reedy
Guest
Posts: n/a
 
      11-09-2008
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.

 
Reply With Quote
 
Kay Schluehr
Guest
Posts: n/a
 
      11-09-2008
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:

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 ).
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      11-09-2008
On Sat, 08 Nov 2008 19:06:14 -0800, walterbyrd wrote:

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


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.



--
Steven

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: [Python-Dev] [python-committers] [RELEASED] Python 3.2 rc 1 R. David Murray Python 0 01-17-2011 02:23 PM
Re: [Python-Dev] [python-committers] [RELEASED] Python 3.2 rc 1 Senthil Kumaran Python 0 01-17-2011 10:31 AM
Re: [Python-Dev] [Python-3000] RELEASED Python 2.6a1 and 3.0a3 Martin v. L÷wis Python 0 03-01-2008 10:51 PM
Re: [Python-Dev] [Python-3000] RELEASED Python 2.6a1 and 3.0a3 Paul Moore Python 0 03-01-2008 10:39 PM
Searching comp.lang.python/python-list@python.org (was: UTF-8) skip@pobox.com Python 0 03-10-2007 02:50 PM



Advertisments