Ian Bicking <i...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
