This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: suggestion: allow termination argument in argparse to be specified as argument
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.6
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Leon Avery, paul.j3, steven.daprano
Priority: normal Keywords:

Created on 2017-07-24 13:40 by Leon Avery, last changed 2022-04-11 14:58 by admin.

Messages (5)
msg298967 - (view) Author: Leon Avery (Leon Avery) Date: 2017-07-24 13:40
In the argparse module, the argument '--' is interpreted as a signal that everything after it is a positional argument. '--' is literally written into the argparse code, in _parse_known_args. This means that a user who wishes to use '--' in some other way is out of luck. 

I suggest the addition of an argument to __init__ (or a method call, or something) that allows '--' to be replaced with some string of the user's choice.
msg298969 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2017-07-24 13:50
> This means that a user who wishes to use '--' in some other way is out of luck. 

I think that's a feature, not a limitation.

Command line arguments should use broadly consistent conventions. I don't want one program to use '--' for "end of options" and another program to use it for "something else".

Suppose you want to use '--' for "foo", and '%%' (say) as the end of options terminator. Whatever foo is. Okay, just swap them -- keep the usual convention where '--' is the options terminator, and use '%%' for foo. That way your users won't be surprised and confused by your application working differently from the great bulk of commandline applications. (Users never read the manual.)

But maybe I'll change my mind if you can show that there's already a very common, and useful, alternative convention of '--' for foo, for some definition of foo.
msg299609 - (view) Author: paul j3 (paul.j3) * (Python triager) Date: 2017-08-01 07:13
argparse roughly follows POSIX practice:

    Guideline 10:
    The first -- argument that is not an option-argument should be 
    accepted as a delimiter indicating the end of options. Any 
    following arguments should be treated as operands, even if they 
    begin with the '-' character.

I don't think this kind of thing is fixed, but there should be good reason to make an enhancement.  For many users argparse is already too complicated, and the docs are hard to understand.  Yet another parameter can get lost.

There are some known problems with this '--', specially when there are more than one.  It may also have problems when used with subparers, though I forget the details.

It wouldn't hard to substitute a CONST variable for this '--', and wouldn't require changes to the API.  

Another possibility is to change this '--' to 'parser.prefix_chars[0]*2'.  Documenting that would be more work than implementing it.  And we'd have to add a unittest case.
msg299701 - (view) Author: Leon Avery (Leon Avery) Date: 2017-08-03 12:15
The POSIX guideline suggests that -- should be available as an option argument. One should be able to say "command --opt --" in order to make '--' the value of the '--opt' option. 

> There are some known problems with this '--', specially when there are more than one.

Yes. That is exactly the problem I have.
msg299729 - (view) Author: paul j3 (paul.j3) * (Python triager) Date: 2017-08-04 02:55
The earlier issue for '--' as arguement

With the patch I suggested there '-f--' and '--foo=--' work as arguments.  '--foo --' is still interpreted as a positionals switch.

In optparse parsing, a flagged option gets all the remaining strings, and consume what it needs.  In the argparse parser, strings are classed as flag and argument and '--'.  The top level allocates strings to Actions.  '--' is handled at the top level.  This difference in parsing makes it impossible to complete replicate POSIX action.

See also
Date User Action Args
2022-04-11 14:58:49adminsetgithub: 75195
2017-08-04 02:55:15paul.j3setmessages: + msg299729
2017-08-03 12:15:39Leon Averysetmessages: + msg299701
2017-08-01 07:13:10paul.j3setmessages: + msg299609
2017-07-30 15:40:28paul.j3setnosy: + paul.j3
2017-07-24 13:50:46steven.dapranosetnosy: + steven.daprano
messages: + msg298969
2017-07-24 13:40:09Leon Averycreate