When argparse will be in the python standard installation

[Steven Bethard]

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