copysort patch, was RE: [Python-Dev] inline sort option (original) (raw)

Guido van Rossum guido at python.org
Mon Oct 20 16:17:23 EDT 2003

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

More information about the Python-Dev mailing list