[stdlib-sig] Breaking out the stdlib

[Michael Foord]

M.-A. Lemburg wrote:
> Jesse Noller wrote:
>   
>> On Tue, Sep 15, 2009 at 12:16 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>>     
>>> 2009/9/15 M.-A. Lemburg <mal at egenix.com>:
>>>       
>>>> Laura Creighton wrote:
>>>>         
>>>>> So what do you think of this proposal?
>>>>>           
>>>> Good write-up and very much to the point.
>>>>
>>>> [Executive Summary:
>>>> Code that hardly needs any changes, because it does what it's meant
>>>> to do, is good code, not bad code. And it causes only minimal
>>>> maintenance effort, so it's actually something core developer should
>>>> welcome rather than fight against.]
>>>>
>>>> I'd only change the tag "dead-as-a-doornail" to "complete, proven and
>>>> stable". Sounds more accurate.
>>>>         
>>> Yes, I like both the summary, and the proposal (that standard library
>>> code be tagged with details like its status and its maintainer).
>>>
>>> I was in the "stdlib needs to evolve" camp, but this has clarified the
>>> other side of the argument, and changed my mind.
>>>
>>> I'm still in favour of new modules being added to the stdlib, and
>>> existing modules being updated, but I support the idea of stage C
>>> (dead as a doornail/complete, proven, stable) modules being retained
>>> indefinitely. I'm not sure what the implications of this position
>>> would be in the case of argparse vs optparse (optparse doesn't seem to
>>> be stage C, so maybe removing it in favour of argparse is an option)
>>> but I like the fact that this proposal gives us terminology on which
>>> we can base the discussion.
>>>
>>> Paul.
>>>       
>> There is no, no such thing as a "dead/complete" module. It does not
>> exist. Any time there is a grammar change, a new reserved keyword, or
>> some other functionality change a "dead" module comes back to life and
>> has to be maintained.
>>
>> Can we please not treat "dead/complete" modules as if they have no
>> maintenance burden, or drag down the code base? The reason I avoided
>> that terminology in the first place is that there is no such thing as
>> code with zero cost.
>>     
>
> We're not treating them like that. All along we said, there is
> /very little/ maintenance needed.
>
> Besides, changes such as keyword fixes, grammar changes, style
> changes, etc. get applied to all stdlib modules, so these fixes
> don't really count as module-specific maintenance. Most of these
> fixes are done via a script or grep/sed anyway, so the cost per
> module is very small.
>
> You can have a look at the getopt SVN log to get an impression
> of just how much effort it takes to keep that module running.
>
> These are all changes applied to the module over a period of 7 years:
>   

This doesn't begin to cover the whole cost of keeping a library and its 
tests in Python. There are all the closed issues that someone has had to 
look into and respond to. Every time a developer runs all of the Python 
tests he pays some cost for every test of every module. Every time 
someone packages, distributes or downloads Python they pay some cost for 
every byte in Python. Every time someone translates the documentation, 
or updates the documentation (which Georg did recently for *every* 
module in the standard library) they pay a cost for every language 
feature and module they touch - or have to make a conscious decision not 
to touch.

There is also a cost in keeping bad modules in the library (something 
that has already been touched on) in user frustration. There is of 
course a cost in removing modules too - documentation and tutorials go 
out of date and need changing. There is definitely an inertia in favour 
of not removing modules - but there is also a hidden cost in keeping 
them. All of this needs to be weighed (carefully).

Michael

> ------------------------------------------------------------------------
> r67572 | georg.brandl | 2008-12-05 10:23:14 +0100 (Fri, 05 Dec 2008) | 2 lines
>
> #4458: recognize "-" as an argument, not a malformed option in gnu_getopt().
>
> ------------------------------------------------------------------------
> r31261 | akuchling | 2003-02-06 20:52:56 +0100 (Thu, 06 Feb 2003) | 4 lines
>
> A few naughty external scripts do 'raise getopt.error, "blah"', and
>    now crash because two arguments are expected.  Add a default value
>    to keep those scripts running.
>
> ------------------------------------------------------------------------
> r27929 | loewis | 2002-08-04 19:22:59 +0200 (Sun, 04 Aug 2002) | 2 lines
>
> Add encoding declaration.
>
> ------------------------------------------------------------------------
> r27780 | jackjansen | 2002-07-26 13:34:49 +0200 (Fri, 26 Jul 2002) | 2 lines
>
> Use os.environ.get() in stead of os.getenv() (which is platform-dependent).
>
> ------------------------------------------------------------------------
> r27645 | tim_one | 2002-07-16 23:35:23 +0200 (Tue, 16 Jul 2002) | 2 lines
>
> Whitespace normalization.
>
> ------------------------------------------------------------------------
> r27095 | montanaro | 2002-06-07 05:26:43 +0200 (Fri, 07 Jun 2002) | 2 lines
>
> gnu_getopt should be exported in __all__
>
> ------------------------------------------------------------------------
> r27077 | loewis | 2002-06-06 20:14:50 +0200 (Thu, 06 Jun 2002) | 2 lines
>
> Use isinstance for the type check, use booleans.
>
> ------------------------------------------------------------------------
> r27068 | loewis | 2002-06-06 12:58:36 +0200 (Thu, 06 Jun 2002) | 2 lines
>
> Patch 473512: add GNU style scanning as gnu_getopt.
>
> ------------------------------------------------------------------------
> r26191 | tim_one | 2002-04-05 00:55:58 +0200 (Fri, 05 Apr 2002) | 2 lines
>
> Convert a pile of obvious "yes/no" functions to return bool.
>
> ------------------------------------------------------------------------
> r24680 | fdrake | 2001-12-12 07:20:34 +0100 (Wed, 12 Dec 2001) | 3 lines
>
> Wrapped a long line.
> Converted to use "".startswith() to avoid slicing (& temp string creation).
>
> ------------------------------------------------------------------------
> r18934 | montanaro | 2001-01-21 00:34:12 +0100 (Sun, 21 Jan 2001) | 2 lines
>
> more __all__ updates
>
> ...
>
> The story is similar for optparse, only that the low maintenance
> mode has started in 2006.
>
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog