[stdlib-sig] Breaking out the stdlib

[M.-A. Lemburg]

Steven Bethard wrote:
> On Mon, Sep 14, 2009 at 3:07 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> and the fact that argparse has been in the wild for 4.5 months.
> 
> Just to set the record straight, argparse's first release was in October 2006:
> 
> http://mail.python.org/pipermail/python-announce-list/2006-October/005304.html

Thanks for clarifying this.

> On Mon, Sep 14, 2009 at 3:37 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>> It turned 1.0 in July and the first release (on Google Code) was on
>> April 1st this year.
> 
> There were many releases on python-hosting.com before argparse moved
> repositories. A quick Google for "argparse release" would have turned
> these up for you.

I did Google for argparse and it did bring up python-hosting.com.
However, the python-hosting.com page redirected straight to
the Google Code page. I also looked on PyPI, but that only listed
the 1.0 release.

>> how much traction can you get in those few months and how likely are
>> API changes to the code in a 1.1 or 2.0 release ?
> 
> This is now completely off topic, but the the core APIs (e.g.
> add_argument, parse_args) haven't really changed since 0.1, and there
> haven't really been any backwards incompatible changes since about 0.5
> (January 2007), and they were preceded by deprecations as in most
> Python modules.

Thanks, that's good to know. So argparse has been stable for
2 years now.

BTW: This is fact is not off-topic at all - we are discussing
evolving the stdlib and Jesse brought up the idea of breaking up the
stdlib as answer to the discussions we had about getopt/optparse/
argparse.

This thread then shifted into a different direction:
that of breaking up the stdlib to make life easier for other
Python implementations than CPython.

And that discussion then led back to the original discussion
about how to evolve the stdlib, since it included deprecation
of modules, which then resulted in my summary of the situation
w/r to the parsing libs.

The two threads "should we try to add argparse?" and
"Breaking out the stdlib" both target the same basic
topic: How much change is needed and wanted in the stdlib ?

Part of the answer involves looking at the maturity of new
code vs. that of the existing code and weighing added
features vs. breaking backwards compatibility.

So to correct my summary: argparse has been stable for 2 years,
optparse for 7 years, getopt for >9 years (the last major
change was in 1998).

Anyway, Frank is going to write a PEP covering splitting the
stdlib into chunks in order to simplify reuse in Jython,
IronPython, etc. so that's a good result.

Just to avoid any misunderstandings: I don't have anything
against argparse or adding it to the stdlib.

I'm only concerned about the effects of deprecating modules
that are in wide-spread use, in this case getopt and optparse,
without providing a drop-in API compatible replacement.

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