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

[Ian Bicking]

On Monday, October 20, 2003, at 01:22 PM, Guido van Rossum wrote:
>> I want the functionality -- any sensible name that might let the
>> functionality into the standard library would be ok by me (so
>> would one putting the functionality in as a builtin or as an instance
>> method of lists, actually, but I _do_ believe those would not be
>> the best places for this functionality, by far).  I hope the "tools
>> package" idea and/or the classmethod one find favour...!-)
>
> 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.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org