Martin said:
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
* alias add_argument to add_option
* alias Values to Namespace
* alias OptionError and OptionValueError to ArgumentError
* alias add_help= keyword argument of ArgumentParser to add_help_option=
* alias namespace= keyword argument of parse_args to options=
* add the has_option, get_option and remove_option methods
* add the set_conflict_handler method
* add the destroy method
* add the set_usage method
* add the string names for types (e.g. "string", "str", "int", etc.) as
aliases to the type objects (argparse already has a type registry for
exactly these kinds of things)
Some slightly harder issues:
* ArgumentParser.parse_args returns a single namespace object, not an
(options, args) tuple, since argparse handles positional arguments.
This could probably be addressed by adding an __iter__ method to the
Namespace object which would return (self, [])
* argparse uses standard string formatting specifiers, e.g. %(default)s
and %(prog)s instead of optparse's %default and %prog. It could
probably be hacked to support both though.
* argparse doesn't support {enable,disable}_interspersed_args() because
their primary use case was for handling sub-parsers, which argparse
handles through the add_subparsers method. It could probably be hacked
to work though I guess.
And the issues that I don't see any good way to address:
* argparse makes the default value for a "store_true" action False, and
the default value for a "store_false" action True. This is what users
expect, but different from optparse where the default is always None.
* the ArgumentParser constructor doesn't accept the option_list=,
option_class= or formatter= keyword arguments. Since argparse uses
Action subclasses instead of a single Option class, the former two
don't make much sense. And formatter= has been replaced with
formatter_class= where the API of the formatter was dramatically
changed. (That said, the formatter API is undocumented in both
optparse and argparse.)
* the choices argument is now checked *after* arguments have been
type-converted. This is intentional, so that you can specify, say
xrange(100) instead of ["0", "1", "2", "3", ... "99"]. There is also
no "choices" type anymore since any action can also specify their
choices.
* argparse doesn't support ``callback`` actions because the same effects
are better handled by defining a simple type-checking function and
passing it as the type= keyword argument, or by subclassing
argparse.Action and passing this as the action= keyword argument.
I could probably add callback actions by creating an appropriate
Action subclass and registering it. However, any code relying on
parser.{largs,rargs,values} would break because the parsing algorithm
is completely different in argparse.
* The `Extending optparse`_ section in the docs is pretty much
completely inapplicable. One of the major goals of argparse was to get
rid of the need to hack class attributes like TYPES, STORE_ACTIONS,
etc. Instead, these things are handled by defining simple
string-to-object functions that are passed to type= or by defining
appropriate subclasses of argparse.Action which are passed to action=.
Trying to support these sorts of things would be nearly impossible.
I guess I don't know how to proceed from here. I'm reluctant to start
adding the code necessary to support even the easily solved issues when
the issues that I don't know how to solve seem like they could be deal
breakers.
STeVe
... _Extending optparse:
http://docs.python.org/lib/optparse-extending-optparse.html