[Python-Dev] PEP 389: argparse - new command line parsing module

Brett Cannon brett at python.org
Sun Sep 27 23:57:34 CEST 2009


I am going to state upfront that I am +1 for this and I encouraged
Steven to submit this PEP on the stdlib-SIG. I still remember watching
Steven's lightning talk at PyCon 2009 on argparse and being impressed
by it (along with the rest of the audience which was obviously
impressed as well).

I think argprase is a good improvement over what we have now (getopt
and optparse), it's stable, considered best-of-breed by the community
for a while (as shown as how many times argparse has been suggestion
for inclusion), and Steven is already a core committer so is already
set to maintain the code. That covers the usual checklist we have for
even looking at a PEP to add a module to the standard library.


On Sun, Sep 27, 2009 at 13:59, Steven Bethard <steven.bethard at gmail.com> wrote:
[SNIP]
> Deprecation of getopt and optparse
> ==================================
> There is still some debate over the best way (if at all) to encourage
> users to move from getopt and optparse to their replacement,
> argparse. The current recommendation of this PEP is the following
> conservative deprecation strategy:
>
> * Python 3.2, Python 2.7 and any later Python 2.X releases --
>  PendingDeprecation warnings, which by default are not displayed,
>  and documentation notes directing users of getopt and optparse to
>  argparse.
>
> * Python 3.3 -- Same as above
>
> * Python 3.4 -- Deprecation warnings for getopt and optparse, which
>  by default *are* displayed.
>
> Though this is slower than the usual deprecation process, it seems
> prudent to avoid producing any casually visible Deprecation warnings
> until Python 3.X has had some additional time to attract developers.
>

Just to give people ideas of how long these deprecations would last,
if Python 3.2 is released in June 2010 and we continue on our 18 month
release schedule (and actually release that quickly which we typically
don't), then getopt/optparse would have a pending deprecation for 3
years (until June 2013) and a deprecation warning for 1.5 years (until
January 2015), so 4.5 years total once the deprecations began and six
years since Python 3.0 came out. And obviously the deprecation can be
extended if it turns out Python 3 pick up is now at a rate we expect
(but only if people who plan to port are having issues; this does not
concern those who plan to stay on Python 2 indefinitely and do not
care about Python 3).

And we can also document suggestions on how to transition off of
getopt/optparse like Steven has in the argparse code
(http://argparse.googlecode.com/svn/tags/r101/doc/argparse-vs-optparse.html#upgrading-optparse-code).

>
> Open Issues
> ===========
> The argparse module supports Python from 2.3 up through 3.2 and as a
> result relies on traditional ``%(foo)s`` style string formatting. It
> has been suggested that it might be better to use the new style
> ``{foo}`` string formatting [13]_. This seems like a good idea, but
> would break backwards compatibility for existing argparse-based
> scripts unless we can come up with a way to reasonably support both
> syntaxes.

I see two solutions to this. One is to auto-detect either format and
then do the right thing. Seems potentially messy, although getting the
regex right shouldn't be a problem.

The other option is to rename the module if it is added to the
standard library ala simplejson/json. That would alleviate any issues
with someone including their own copy of argparse with their
application using %()s string interpolation over {}. I don't have a
name to suggest at the moment (nor do I think we should start
discussing that now unless this is a chosen solution), but it would
deal with the problem.

Either way, with {} being the future and talk of someday dropping %, I
think we should make sure the newer syntax is at least supported, if
not the only way to do things.

-Brett


More information about the Python-Dev mailing list