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

[Michael Foord]

Brett Cannon wrote:
> 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.
>
>   

I've used argparse and really like it. I could also have done with the 
subcommand support in recent changes to unittest.

+1 for inclusion.

Michael


> 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
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>   


-- 
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog