No subject

Mon Jan 18 10:37: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:
> 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:
> 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
> 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! -

More information about the Python-Dev mailing list