[Python-Dev] Pronouncement on PEP 389: argparse? (original) (raw)

Ben Finney ben+python at benfinney.id.au
Mon Dec 14 23:43:52 CET 2009

Ian Bicking <ianb at colorstudy.com> writes:

Ideally I really wish ArgumentParser was just named OptionParser, and that .addargument was .addoption, and that argparse's current parseargs was named something different, so both the optparse parseargs (which returns (options, args)) and argparse's different parseargs 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 parseargs 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

More information about the Python-Dev mailing list