list.sorted() vs. list.copysort() (was Re: Newbie Questions: Swithing from Perl to Python)

[Aahz]

In article <roy-57494B.09031926102003 at reader1.panix.com>,
Roy Smith  <roy at panix.com> wrote:
>In article <bnfmnv$fqd$1 at panix3.panix.com>, aahz at pythoncraft.com (Aahz) 
>wrote:
>> In article <roy-D86C06.22163525102003 at reader1.panix.com>,
>> Roy Smith  <roy at panix.com> wrote:
>>>
>>>My personal opinion is that you should be able to do the simplier:
>>>
>>>for key in myDict.keys().sort()
>>>   print key
>>>
>>>but unfortunately, sort doesn't work like that.  It sorts the list 
>>>in-place and does NOT return the sorted list.
>> 
>> Yup.  Guido doesn't want you copying the list each time you sort; it's
>> easy enough to make your own copy function.  Nevertheless, it appears
>> likely that 2.4 will grow list.sorted() (yes, a static method on the
>> list type).
>
>What do you mean by "a static method on the list type"?  Will I be able 
>to do:
>
>   for key in myDict.keys().sorted():
>      print key

Nope:

    for key in list.sorted(myDict.keys()):
        print key

>If that's what you're talking about, there's an obvious downside, which 
>is that now we'll have list.sort() and list.sorted() which do two 
>different things.  This will be confusing.

Yup.  I pointed that out; I preferred copysort(), but the fact that you
have to actually use the list object to access the method separates the
namespace at least.  I'm -0 on the current name, but Guido likes it.

>Is there a PEP on this I could read?  A quick look at the PEP index 
>didn't show anything that looked appropos.

No, this was considered a small enough addition to warrant restricting
the discussion to python-dev.  If other people pipe up with objections,
I'll forward that back to python-dev.

>I certainly understand the efficiency aspects of in-place sorting, but 
>this has always seemed like premature optimization to me.  Most of the 
>time (at least in the code I write), the cost of an extra copy is 
>inconsequential.  I'll be happy to burn a few thousand CPU cycles if it 
>lets me avoid an intermediate assignment or a couple of extra lines of 
>code.  When things get too slow, then is the time to do some profiling 
>and figure out where I can speed things up.

It's not so much that as that it's much easier to get a copying sort (by
making your own copy) than it is to get a non-copying sort.  The
efficiency issue here is less the CPU cycles than the RAM, and people
*do* sort lists with thousands or millions of elements.  Python is in
many ways about keeping people from shooting themselves in the "worst
case".
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan