[issue9571] argparse: Allow the use of -- to break out of nargs and into subparser

[Michael . Elsdörfer]

New submission from Michael.Elsdörfer :

argparse already seems to support -- to indicate that what follows are 
positional arguments. However, I would like to parse something like:

./script.py --ignore one two -- COMMAND

I.e., --ignore is an nargs='+' argument, and I need a way to break out of 
--ignore and have argparse consider what follows on it's own merits. If COMMAND 
in the above example refers to a subparser, this won't work:

error: invalid choice: '--' (choose from 'command1', 'command2', 'command3')

I'm not sure what's the best solution here. Allowing -- here would change the 
semantics of forcing everything that follows to be positional arguments, since 
the subparser might have flags. I'm not sure if that is what is required by 
Unix conventions, but if not, then I think it makes sense to allow -- to be 
followed by a subparser.

--
components: Library (Lib)
messages: 113616
nosy: elsdoerfer
priority: normal
severity: normal
status: open
title: argparse: Allow the use of -- to break out of nargs and into subparser
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue9338] argparse optionals with nargs='+' can't be followed by positionals

[Michael . Elsdörfer]

Changes by Michael.Elsdörfer :


--
nosy: +elsdoerfer

___
Python tracker 

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

[issue13968] Support recursive globs

[Michael . Elsdörfer]

Michael.Elsdörfer  added the comment:

This should absolutely be implemented as **:

- It is pretty much standard. Recursive globbing is not supported everywhere, 
but when it is, ** is used.

- A separate function will not allow me to let the *user* to decide when 
recursion should be used. I find this most important. When I need to find files 
internally, I always do so using os.walk etc. When I use glob, it is because I 
want to provide an interface to my users. 

- The change to support ** is actually pretty trivial. I have implemented this 
as a module here: https://github.com/miracle2k/python-glob2/

- It's backwards-compatible - or close enough anyway. ** is currently perfectly 
nonsensical, making it a meaningful syntax element is acceptable, I think.

--
nosy: +elsdoerfer

___
Python tracker 

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

[issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()

[Michael . Elsdörfer]

Changes by Michael.Elsdörfer :


--
nosy: +elsdoerfer

___
Python tracker 

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

[issue9540] argparse: combine subparsers with global positional args

[Michael . Elsdörfer]

New submission from Michael.Elsdörfer :

>>> parser = argparse.ArgumentParser()
>>> subparsers = parser.add_subparsers(title="commands")
>>> subparser = subparsers.add_parser('make')
>>> parser.add_argument('jobs', nargs='*')
>>> parser.print_help()
usage: [-h] {make} ... [jobs [jobs ...]]

While the printed usage looks innocuous enough, argparser isn't actually able 
to parse this the way I expect: The positional argument never get's to handle 
any jobs given, as apparently everything after the command is handled by the 
subparser:

>>> parser.parse_args(['make', 'something'])
usage:  make [-h]
 make: error: unrecognized arguments: something

It seems that argparse, upon determining that the subparser can't handle a 
positional argument, could break out of the subparser, and let the parent 
parser continue. If necessary, as further help for argparse on how to resolve 
such situations, a parameter could be added to add_subparsers() which would 
allow the user to indicate that this group of subparsers should not support 
positional arguments.

The usage string should then print as:

>>> parser.print_help()
usage: [-h] {make} [jobs [jobs ...]]

That is, without the "..." after the command.

Finally, if it is decided that the feature will not be added, argparse should 
not allow the user to add positional arguments after a subparser.

--
components: Library (Lib)
messages: 113229
nosy: elsdoerfer
priority: normal
severity: normal
status: open
title: argparse: combine subparsers with global positional args
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

[issue9253] argparse: optional subparsers

[Michael . Elsdörfer]

Changes by Michael.Elsdörfer :


--
nosy: +elsdoerfer

___
Python tracker 

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

[issue9253] argparse: optional subparsers

[Michael . Elsdörfer]

Michael.Elsdörfer  added the comment:

To expand on my case from issue9540, I have a bunch of commands, each of which 
should enable a specific subset of options only available the individual 
command, but all of the commands share the same behavior in taking nargs='*' 
positional arguments:

./script.py --global-option command --command-option arg1 arg2 arg3

For example:

./backups.py -c /etc/tarsnap.conf make --no-expire job1 job2

If no positional arguments are given, all jobs defined in the config file are 
run. Or, in the above example, only "job1" and "job2" are run.

The positional arguments are the same for *all* commands. Now I can define them 
separately for each subparser, which is what I'm currently doing, but I kind of 
like having the global usage instructions (script.py -h) indicating the fact 
that positional arguments can be passed after the command. 

In fact, right now I'm able to sort of achieve this by defining the positional 
nargs arguments both globally (to have them show in usage) and in each 
subparser (to have them parsed). This wouldn't be possible anymore if argparse 
where to throw an error after adding arguments after a subparser, although 
probably a more correct behavior.

Anyway, while the two issues are clearly related, I don't think that the two 
are necessarily mutually exclusive. argparse could allow both optional 
subparsers (if no subparser matches), as well as pass control back to the 
parent parser once an already matched subparser is no longer able to handle 
further command line input. Or optionally, support defining subparsers as 
"options only", so that positional arguments would always be handled by the 
parent parser.

Now, I can see how this could potentially become messy if we start talking 
about these positional arguments handled by the parent then being followed by 
more flags, which would then presumably also be handled by the parent etc. On 
the other hand, my use case doesn't seem that strange to me.

--

___
Python tracker 

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