[Python-Dev] PEP 389: argparse - new command line parsing module (original) (raw)

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