[stdlib-sig] Breaking out the stdlib

[M.-A. Lemburg]

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:

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

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 15 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/