[stdlib-sig] Breaking out the stdlib

[M.-A. Lemburg]

Michael Foord wrote:
> M.-A. Lemburg wrote:
>>> 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.

It was meant a proof for the code being mature and causing
low maintenance costs.

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

Right, I didn't say there were no costs, but then how does the above
time compare to e.g. fixing two nasty bugs in a newly adopted module ?

You can easily spend a day or two trying to track down such bugs.
Certainly more than you spend on doing the things you mentioned
above for a module that doesn't have all that many issues.

> There is also a cost in keeping bad modules in the library (something
> that has already been touched on) in user frustration.

Nobody forces a user to use a "bad" module (for whatever meaning
the user associates with "bad"). That's what so great about Python:
there are a gazillion 3rd party modules out there waiting to
get used.

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

Sure.

What I'm trying to say is that keeping a module in the stdlib
costs less than removing it - for everyone.

I've been maintaining our eGenix mx Series for more than a decade
now, so I do know a little about such costs, where to expect them
and where not.

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