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