[stdlib-sig] should we try to add argparse?

[M.-A. Lemburg]

Brett Cannon wrote:
> On Thu, Sep 10, 2009 at 15:40, Jim Baker <jbaker at zyasoft.com> wrote:
>> +1 - I don't want Python being like Java where the only deprecation that
>> occurs is when code is actively harmful - and it still won't be removed for
>> backwards compatibility's sake.
> 
> The deprecation would be permanent, so it won't be like Java where we
> support stuff only until we consider it harmful. And unlike Java we
> would not keep the docs around forever, suggesting that you can just
> simply ignore what the docs say. The modules would eventually
> disappear from people's knowledge.
> 
> This idea is not far off from what we already do. There were a bunch
> of deprecated modules in the standard library I ripped out for Python
> 3 that had been slated for removal for ages. It's just nobody bothered
> to remove them.

Right and this was done when transitioning from 2.x to 3.x - which
is fine. Backwards compatibility can be broken in such major release
steps.

However, it should be noted that the deprecated modules were mostly
targeting obsolete architectures, their functionality was moved
to other modules, or they were so obscure that the number of people
using them warranted deprecating and then finally removing them.

None of the above applies to the getopt and optparse modules.

getopt mimics the C level function of the same name and provides
an easy entry for C programmers. It has this approach in common
with many other Python modules and exposed APIs.

optparse has a more Python-friendly approach to option parsing.

Both serve their needs and both are in common use.

Note that the purpose of the stdlib is to provide tools to be
able to get things working without having to rely on 3rd party
tools.

The main motivation behind the stdlib is stability and soundness,
much more than providing the latest and greatest gimmicks you can
possibly imagine. It provides the basic set of tools (and does
an very good job at this).

Users are free to use other modules or libraries, if they believe
that a certain API or way of doing things suits them better.

Just because one group of people thinks that the shiny brand
new method B suits them better, doesn't mean that it's OK to
put the extra burden of porting applications using method A
to method B on the happy users of method A.

Even less so, since nothing stops people from using method B
by downloading and installing their favorite tool from PyPI.

And another aspect to consider: instead of replacing existing
tools with new ones, it's often better to think a little harder
and add the missing functionality to the existing tools.
That approach buys you more features and more stability at
much lower maintenance costs.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 11 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/