Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #98346 > unrolled thread

Re: argparse: use of double dash to separate options and positional arguments

Started byAmit Ramon <amit.ramon@gmail.com>
First post2015-11-06 13:44 +0200
Last post2015-11-06 13:44 +0200
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: argparse: use of double dash to separate options and positional arguments Amit Ramon <amit.ramon@gmail.com> - 2015-11-06 13:44 +0200

#98346 — Re: argparse: use of double dash to separate options and positional arguments

FromAmit Ramon <amit.ramon@gmail.com>
Date2015-11-06 13:44 +0200
SubjectRe: argparse: use of double dash to separate options and positional arguments
Message-ID<mailman.82.1446810309.16136.python-list@python.org>
Peter Otten <__peter__@web.de> [2015-11-06 11:57 +0100]:


>>
>> For example, with the above code
>>
>>     my_prog -v hello world
>>
>> works well, but
>>
>>     my_prog -v -x hello world
>>
>> Fails with an error message 'error: unrecognized arguments: -x'.
>
>This looks like a bug to me. Please report it on bug.python.org.

Why does it looks like a bug? To me it seems okay - argparse expects
that an argument that starts with '-' is an option, and it also expects
to be told about all possible options, so it complains on
encountering an unrecognized 'option'. This is why a special delimiter
is needed to mark the 'end of options'.


>
>> If I invoke the program with a '--' at the end of the options (as I
>> understand is a common standard and a POSIX recommendation), as in:
>>
>>     my_prog -v -- -x hello world
>>
>> It works well again.
>>
>> However, a few questions remain:
>>
>> Firstly, as far as I can tell the use of '--' is not documented in the
>> argparse documentation (but the code of argparse clearly shows that it
>> is a feature).
>>
>> Secondly, when using '--', this string itself is inserted into the
>> list of the collected positional arguments (in the above example in
>> the cmd_args variable):
>>
>> $ ./my_prog -v -- -x hello world
>> Namespace(cmd_args=['--', '-x', 'hello', 'world'], verbose=True)
>>
>> It's quiet easy to check for it and remove it if it exists, but it
>> still seems like it shouldn't be there - it is not really an argument,
>> just a delimiter.
>
>I'm not sure about this one; one purpose of REMAINDER is to pass on the
>unprocessed arguments to another program/script, and this might follow the
>same convention. Should
>
>parser.add_argument('-v', '--verbose', action='store_true')
>parser.add_argument('cmd_args', nargs=argparse.REMAINDER)
>args = parser.parse_args()
>subprocess.call(["rm"] + args.cmd_args)
>
>$ my_prog -v -- -r foo
>
>attempt to delete two files "-r" and "foo" or remove the "foo" directory?
>The first is the safer alternative, and as you say stripping the "--" is
>easy.

I'm using the REMAINDER exactly for passing on arguments to another
program, as in your example. I would expect that everything after
the '--' should be passed on as is - it should be up to the other
program to decide what to do with the arguments it receives (So in
your examples, rm would actually try to remove the "foo" directory).

And although stripping the '--' is easy, why should the user of
argparse need to handle it? Still unclear to me.

Cheers,

Amit

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web