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

[Ben Finney]

Ian Bicking <ianb at colorstudy.com> writes:

> Ideally I really wish ArgumentParser was just named OptionParser, and
> that .add_argument was .add_option, and that argparse's current
> parse_args was named something different, so both the optparse
> parse_args (which returns (options, args)) and argparse's different
> parse_args return value could coexist.

-1 for pretending that “option” and “argument” mean the same thing. They
really don't (the former is a strict subset of the latter), and it would
be confusing legacy cruft if argparse had names that imply it. The names
chosen in the argparse library are good.

> if OptionParser really was a different class then maybe parse_args
> should act the same as optparse.OptionParser.

+1 for “optparse API and external behaviour re-implemented as an
‘optparse’ module using argparse as the underlying implementation”, to
allow exactly the sort of ease of transition you're describing.

Of course, that +1 is only support for “someone else does the work”. I
don't need optparse to remain if I have argparse in the standard
library. +0 for deprecating optparse.

-- 
 \        “… it's best to confuse only one issue at a time.” —Brian W. |
  `\    Kernighan and Dennis M. Ritchie, _The C programming language_, |
_o__)                                                             1988 |
Ben Finney