[Python-Dev] Pronouncement on PEP 389: argparse?

anatoly techtonik techtonik at gmail.com
Sun Dec 27 18:51:54 CET 2009


On Tue, Dec 15, 2009 at 12:37 AM, Steven Bethard
<steven.bethard at gmail.com> wrote:
>
> If you're only concerned about 2.X, then yes, optparse will *never* be
> removed from 2.X. There will be a deprecation note in the 2.X
> documentation but deprecation warnings will only be issued when the -3
> flag is specified. Please see the "Deprecation of optparse" section of
> the PEP:
>
> http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse

I do not think that optparse should be deprecated at. It is good at
what it does and its limitations make its starting point less
confusing for people with different backgrounds that Python.

Compare:
http://docs.python.org/library/optparse.html
http://argparse.googlecode.com/svn/tags/r101/doc/index.html

argparse should be recommended as advanced and more featured variant
of optparse - that goes without saying, but forcing people to switch
and annoying them with deprecation messages brings only headache. Just
like optparse is better getopt, the latter could also be useful for
people coming from other languages and porting their libraries to
Python.

I would better concentrate on real code examples how argparse solves
problems and would really want to see
http://www.python.org/dev/peps/pep-0389/#out-of-scope-various-feature-requests
implemented until argparse enters phase where backward incompatible
changes in API are impossible.

I would prefer to see PEP 389 as a document describing proposed
solutions to argument parsing problems rather than petition to replace
one library with another. So, it should display common argument
parsing scenarios (use cases) with examples that are also useful
recipes for documentation. I guess more than 90% people here doesn't
have time to read argparse methods descriptions to see what they could
be useful for.

-- 
anatoly t.


More information about the Python-Dev mailing list