As discussed on py-dev, this returns a sorted copy of a
list while leaving the original intact.

Logged In: YES 
user_id=80475

Revised the patch to avoid an unnecessary copy whenever the
underlying object is not referenced anywhere else -- this
occurs in the common use case:  for elem in
d.keys().copysort(): . . .

Logged In: YES 
user_id=80475

Rationale for the change
---------------------
An inline sort is usable anywhere an expression is allowed.
 This includes important places like function call arguments
and list comprehensions:

  todo = [t for t in tasks.copysort() if due_today(t)]

  genhistory(date, events.copysort(key=incidenttime))

Spreading these out over multiple lines is an unnecessary
distractor from the problem domain, making the code harder
to understand and maintain.

Also, using copysort() eliminates a unnecessary variable
that changes state from unsorted to sorted and has a
lifetime longer than the data is actually needed. In longer
code fragments, this decreases code complexity, code length,
the number of variables, and decreases the risk of using a
variable in the wrong state which is a common source of
programming  errors.

Logged In: YES 
user_id=80475

Alex, can you give this patch a second review.

I did not put in additional classmethod warnings because all
plausible misunderstandings raise an error anyway.

Logged In: YES 
user_id=80475

Applied.

Logged In: YES 
user_id=60314

Looks good to me!  I understand not wanting -- given the clean and
spare code for list.sorted -- to go to the considerable trouble needed
to give more specific error messages; however, if we release like this
we WILL get questions about it on c.l.py and help@python.org -- "why doesn't ''for x in mydict.keys().sorted():'' work?!" etc.  Do you mind if
eventually I _do_ try to ensure the error messages specifically mention list.sorted being a classmethod and requiring one iterable argument?