A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/2010-January/097027.html below:

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

[Python-Dev] Pronouncement on PEP 389: argparse? [Python-Dev] Pronouncement on PEP 389: argparse?Daniel Fetchinson fetchinson at googlemail.com
Mon Jan 4 10:32:10 CET 2010
>> 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.

As has been noted already nobody is forcing people to switch. Optparse
will be available as a separate package and everybody will be free to
install it and will not have any deprecation messages anywhere.

> 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.



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4