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

[Collin Winter]

On Thu, Sep 10, 2009 at 6:36 PM, M.-A. Lemburg <mal at egenix.com> wrote:
> Michael Foord wrote:
>> So we're stuck with inferior technology?
>
> If you have the choice between breaking backwards compatibility
> and downloading other implementations from PyPI, I think backwards
> compatibility counts more.

Why doesn't this argument apply to getopt and optparse equally? Once
they've gone through the multi-year deprecation process and have been
finally removed, they can be put up on PyPI as stand-alone release to
support users who can't/won't migrate to argparse.

> We've just had a major change in the stdlib for 3.x. Then the 3.0
> release was ditched due to poor performance. If we now start
> deprecating widely used modules in 3.2, we're going to lose
> a major pro argument for using Python: that of a stable eco system
> to write code for.

The language can be stable, but if the entire 3.x series is just a
series of bugfixes on top of 3.0's stdlib, then that's a poor state of
affairs. That's the price users pay for shiny, new things: the old,
crufty things have to go away eventually, and I think it's unrealistic
to wait another 10 years for a hypothetical Py4k project to remove
getopt.

> I don't think we should deprecate any commonly used module (in the
> 3.x branch) unless there's a clear and documented migration path
> or -even better- a migration wrapper available for the deprecated
> module.

Agreed. There should be a documented cookbook for migrating from
getopt/optparse to argparse; I can't imagine that it's anyone's
intention to throw users in the deep end without any aid. Perhaps
simple cases could be handled automatically by a refactoring tool
based on 2to3 (in the same way that 3to2 is based on 2to3), which I
imagine many users would prefer.

Collin Winter