When argparse will be in the python standard installation

[Steven Bethard]

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.

Martin v. Löwis wrote:
 > It's not necessary that the implementation is retained, only that the
 > interface is preserved.
[snip]
 > If you need to make incompatible changes, it would be best if you
 > could produce a list of such changes

Steven Bethard writes:
 > FWIW, here's a short list of issues that could be easily addressed:
 >
 > * alias ArgumentParser to OptionParser
[snip]

John J. Lee wrote:
> all of these issues could ... be addressed by instead providing both
> OptionParser and an OptsAndArgsParser class (or whatever you'd call
> the latter).

You're essentially proposing to move argparse.ArgumentParser to the 
optparse module. (The ArgumentParser class handles both optional and 
positional command-line args -- it *is* your OptsAndArgsProcessor).

That's certainly an easy option for me =) but does it address Martin and 
Fredrik's concerns that there are already too many argument parsing 
libraries in the stdlib?

> Presumably most of the actual implementation code
> would be shared.

Well, the "harder issues" I listed in the previous post were basically 
the reasons that sharing the implementation code would be difficult. I 
don't know how to do it without breaking OptionParser in backwards 
incompatible ways. (The documented ways of extending optparse make this 
particularly difficult since they make public a number of internal 
optparse details.)

STeVe