Steven Bethard <[EMAIL PROTECTED]> writes: > Martin v. Löwis wrote: > > Steven Bethard schrieb: > >> If someone has an idea how to include argparse features into optparse, > >> I'm certainly all for it. But I tried and failed to do this myself, so I > >> don't know how to go about it. > > It's not necessary that the implementation is retained, only that the > > interface is preserved. So if you can come up with an implementation > > that supports all optparse applications, and adds the additional > > features, your implementation could replace the current optparse. > > If you need to make incompatible changes, it would be best if you > > could produce a list of such changes, so that optparse users can > > review them to find out whether they are affected. > > FWIW, here's a short list of issues that could be easily addressed: > > * alias ArgumentParser to OptionParser [...snip long list of proposed aliases and additions...]
> Some slightly harder issues: [...] You propose here to attempt to merge optparse and argparse into a single interface (single class, by the sound of it). I stopped reading after a bit, but at least up to that point, all of these issues could (and certainly should, if argparse is added to the stdlib, even in Python 3) be addressed by instead providing both OptionParser and an OptsAndArgsParser class (or whatever you'd call the latter). OptionParser would then support exactly the current optparse.OptionParser interface. OptsAndArgsProcessor would support your new interface. Presumably most of the actual implementation code would be shared. John -- http://mail.python.org/mailman/listinfo/python-list
