copysort patch, was RE: [Python-Dev] inline sort option
Guido van Rossum
guido at python.org
Mon Oct 20 15:24:33 EDT 2003
> > 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/)
More information about the Python-Dev