[stdlib-sig] Breaking out the stdlib

[M.-A. Lemburg]

Paul Moore wrote:
> 2009/9/15 Michael Foord <michael at voidspace.org.uk>:
>> Right - but part of the specific problem with optparse is that in many
>> situations it does a very inadequate job (i.e. it "it does what it is meant
>> to do" but not what many people "need it to do") and is designed in such a
>> way that *required* functionality can't be added in a backwards compatible
>> way.
>>
>> That is not "good code" (by my reckoning).
> 
> As such, optparse needs to change (assuming that the stdlib *should*
> be "good code"). There are requirements (feature requests at least,
> possibly even bugs) which need addressing.
> 
> If no maintainer can be found to do this, then optparse is de facto
> dead and unmaintained.(Laura's B-2). No-one has made a statement about
> what should be done with B-2 code in the stdlib, but I can see good
> arguments for allowing the possibility of dropping it in favour of a
> replacement library.
> 
> If someone wants to argue that optparse is class "C" (ie, it is
> "finished" and "complete") then that's a different matter. Requests
> for optparse to support required arguments, or to better support user
> extension, would then be closed "won't fix - this is by design". And
> in that case, it *is* more or less by definition "good code" - it
> fulfills its aims, it just doesn't aim to do what Michael states many
> people "need it to do" above. (Personally, I don't see that code can
> be described as "good" if it doesn't aim to do what people need, but
> maybe someone wants to argue this).

Please note that adding functionality to such class "C" module
is still allowed - provided it doesn't break anything. This has
been done with optparse and getopt a few times already and
is common practice with other such modules as well.

In Laura's particular case, there does appear to be an easy
solution which adds just that one feature:

http://code.activestate.com/recipes/573441/

Things do get problematic if you want to approach a problem
from a whole new angle, e.g. say you want to have XML DOM
parsing instead of SAX parsing.

In such a case, adding a whole new module would be better.
Even though you're still parsing XML in both cases, the new
module would provide a new method to do so. Much like the
urllib2 provides a new and different way to handle URL
fetching compared to urllib.

There's also a third case: If a module cannot be updated
or extended to support a major new feature mandated by
the Python language, such as Unicode support, then there
is little choice other than to replace it with a new module.

This has happened with the pcre module that used to drive
the re module - there was no way to get Unicode into pcre.
The change was not really noticeable to the users, though,
since the new module implemented the same API (and extended
it).

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