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 -- http://mail.python.org/mailman/listinfo/python-list
