Ian Bicking ianb@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.