When argparse will be in the python standard installation

[John J. Lee]

Steven Bethard <steven.bethard at gmail.com> 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