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

[Guido van Rossum]

> > I'm still unclear why this so important to have in the library when
> > you can write it yourself in two lines.
> 
> Probably "there should only be one way to do something."  It's 
> something that is recreated over and over, mostly the same way but 
> sometimes with slight differences (e.g., copy-and-sort versus 
> sort-in-place).  Like dict() growing keyword arguments, a copy/sort 
> method (function, classmethod, whatever) will standardize something 
> that is very commonly reimplemented.  Another analogs might be True and 
> False (which before being built into Python may have been spelled 
> true/false, TRUE/FALSE, or just 0/1).  These don't add any real 
> features, but they standardize these simplest of idioms.
> 
> I think I've seen people in this thread say that they've written Big 
> Python Programs, and they didn't have any problem with this -- but this 
> is a feature that's most important for Small Python Programs.  Defining 
> a sort() function becomes boilerplate when you write small programs.  
> Or alternatively you create some util module that contains these little 
> functions, which becomes like a site.py only somewhat more explicit.  A 
> util module feels like boilerplate as well, because it is a module 
> without any conceptual integrity, shared between projects only for 
> convenience, or not shared as it grows organically.  "from util import 
> sort" just feels like cruft-hiding, not real modularity.

That's one of the best ways I've seen this formulated.

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()...)

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