copysort patch, was RE: [Python-Dev] inline sort option

[Guido van Rossum]

> >That's one of the best ways I've seen this formulated.
> 
> Does this extend by analogy to other requests for short functions
> that are commonly reimplemented?  Not that any spring to mind at the
> moment; it just seems to me that inline sorting is one of a set of
> perennially requested such functions or methods, where the current
> standard answer is "but you can do it yourself in only X lines!".

Only if there's some quirk to reimplementing them correctly, and only
if the need is truly common.  Most recently we did this for sum().

> >If Alex's proposal to have list.sorted() as a factory function is
> >acceptable to the non-English-speaking crowd, I think we can settle on
> >that.  (Hm, an alternative would be to add a "sort=True" keyword
> >argument to list()...)
> 
> Wouldn't it need to grow key and cmpfunc, too?

Yes, but list.sorted() would have to support these too.  It might
become slightly inelegant because we'd probably have to say that
sorted defaults to False except it defaults to True if either of cmp,
and key is specified.  Note that reverse=True would not imply sorting,
so that

  list(range(10), reverse=True)

would yield

  [9, 8, 7, 6, 5, 4, 3, 2, 1, 0]

But Raymond has a different proposal in mind for that (he still needs
to update PEP 322 though).

So maybe list.sorted() is better because it doesn't lend itself to
such generalizations (mostly because of the TOOWTDI rule).

--Guido van Rossum (home page: http://www.python.org/~guido/)