When argparse will be in the python standard installation

["Martin v. Löwis"]

Steven Bethard schrieb:
> * 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=

Not sure what you mean by "alias": I don't think the argparse names
should be retained (unless you feel they describe things better).
You don't need to aim for argparse compatibility: users of argparse
can continue to use the current (or future) version of argparse as
a separate module.

> * 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, [])

I find that I'm not that familiar with command line arguments :-)

To understand that difference, I would have to see examples of both,
and why it is better to return a single result.

In any case, if the argparse interface is more powerful, and the
old interface cannot be emulated transparently, a new interface could
be added, with the old one deprecated and phased out (preferably with
some conversion guideline). It would be possible to drop the old one
in Py3k, I guess.

> * 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.

That would be good.

> * 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.

Could we deprecate "store_false" with no default? It may be that users
expect to see True and False, but how can you find out whether the
option was given or not afterwards?

Alternatively, could the actions become keyword arguments (with the
action argument only preserved for backwards compatibility)? E.g.

parser.add_option("-v", store_true_into="verbose")
parser.add_option("-q", store_false_into="verbose")
(same for store, append, count, callback)

> * 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.

As an incompatible change, this could be warned-about if the type is not
string, yet the first choice is.

Alternatively, we could require users that pass converted values to
specify converted_choices=True in 2.6, and warn all users that don't
pass a converted_choices flag, and then flip the default in 2.7 and 3.0.
Then current users had a quick fix to silence the warning, and new
users could drop the extra flag in the future.

>   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.

If you can find a way to make callbacks work in the "common case",
this flag could be deprecated and removed.

> 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.

This asks for a PEP. The views above are mine only, others may feel
differently.

Regards,
Martin