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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4