[issue9253] optional subparsers

[Vincent Driessen]

New submission from Vincent Driessen :

**NOTE**: This is a re-post of 
http://code.google.com/p/argparse/issues/detail?id=47

What steps will reproduce the problem?
parser = argparse.ArgumentParser()
sub = parser.add_subparsers()
sub.add_parser("info")
parser.add_argument("paths", "+")
parser.parse_args(["foo", "bar"])

What is the expected output? What do you see instead?
Expected behavior is that, failing to match one of the subparser inputs
("info"), the parser checks if the argument matches any of the top-level
arguments, in this case the 'paths' multi-arg. In other words, it should be
possible to make the subparser be optional, such that when the subparser
argument fails to retrieve any valid subparser, the remaining args are
parsed as if no subparser exists. At present, it does not seem possible to
make a subparser be optional at all.
Perhaps this could be exposed to the user as:
parser.add_subparsers(nargs=argparse.OPTIONAL)
or something to that effect. Or, allow a default subparser to be specified.
I.e.,

sub = parser.add_subparsers()
info = sub.add_parser("info")
main = sub.add_parser("main")
sub.default = main

I'm sure the point will come up that the current behavior is correct,
because given a subparser like "info", a user could easily make a mistake
like "myapp ino foo bar" and rather than get a safe error be given
something unexpected. For this reason, I think the default behavior is
usually going to be correct. BUT, it would still be nice if it could be
optional, so that developers could be free to make that call. Sometimes the
potential user errors aren't really an issue, and having to explicitly set
a subparse arg every time can be a nuissance.

--
components: Library (Lib)
messages: 110231
nosy: nvie
priority: normal
severity: normal
status: open
title: optional subparsers
type: feature request
versions: Python 2.7, Python 3.2, Python 3.3

___
Python tracker 
<http://bugs.python.org/issue9253>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9253] argparse: optional subparsers

[Vincent Driessen]

Vincent Driessen  added the comment:

Changed the title, so it shows that the feature request is for argparse.

--
title: optional subparsers -> argparse: optional subparsers

___
Python tracker 
<http://bugs.python.org/issue9253>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9253] argparse: optional subparsers

[Vincent Driessen]

Vincent Driessen  added the comment:

Actually, this is a rather common concept. Broadly used tools like for example 
Git use this kind of subcommand handling.

This command shows all remotes:
   git remote(i.e. is like git remote list)

Showing/removing remotes is done using subsubcommands:
   git remote show [...]
   git remote rm [...]

That, in combination with the explicit design goal that "[argparse] isn't 
dogmatic about what your command line interface should look like" should be 
enough reason to be wanting this, in my humble opinion.

--

___
Python tracker 
<http://bugs.python.org/issue9253>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com