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.

classification
Title: In argparse, allow REMAINDER(...) arguments in a mutually exclusive group
Type: behavior Stage: patch review
Components: Library (Lib) Versions: Python 3.9
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Shani Armon, paul.j3, rhettinger, taleinat
Priority: normal Keywords: patch

Created on 2020-05-05 10:30 by Shani Armon, last changed 2022-04-11 14:59 by admin.

Pull Requests
URL Status Linked Edit
PR 19919 open Shani Armon, 2020-05-05 11:27
Messages (9)
msg368126 - (view) Author: Shani Armon (Shani Armon) * Date: 2020-05-05 10:30
Options specified with the REMAINDER nargs should be treated as optional.
And an empty list should be treated as default.
msg368213 - (view) Author: paul j3 (paul.j3) * (Python triager) Date: 2020-05-05 23:52
Handling the positional with '?' and '*' in a mutually_exclusive_group is tricky enough!

I believe your user can use the '--' to get the same effect.
msg368227 - (view) Author: Shani Armon (Shani Armon) * Date: 2020-05-06 05:34
Why is REMAINDER any more complicated than ZERO_OR_MORE? I need to make a subcommand system (think jupyter style) and -- isn't an intuitive interface. Jupyter just doesn't use argparse in the subcommand case. I prever to in order to support options given before the subcommand, outside the mutually exclusive group (like -C for git)
msg368282 - (view) Author: paul j3 (paul.j3) * (Python triager) Date: 2020-05-06 17:02
A flagged argument with REMAINDER works just fine in a mutually exclusive group.

group.add_argument('-g', nargs='...')

positionals in such a group can only have ? or *.  If you check the code, and past issues you'll see that those require some special handling.  Normally that kind of positional is always 'seen', because an empty list (not strings) satisfies those nargs. One positional can work in a mutually exclusive group because it's been made to work, not because the fit is natural.

Search past issues for REMAINDER to check whether your concerns have been raised before.   If I recall correctly, even without a group, handling a flagged argument with REMAINDER is more robust than a positional.
msg368284 - (view) Author: Shani Armon (Shani Armon) * Date: 2020-05-06 17:11
Yes. The pull request contains the special handling. For the purpose of REMAINDER positionals, the default is changed to the empty list that was returned if no arguments were passed. 

For the purpose of positional argument, that is equivalent to nothing being passed
msg368323 - (view) Author: Shani Armon (Shani Armon) * Date: 2020-05-07 06:23
Also, this is quite different from previous issues with REMAINDER. This fits in line with how the example suggests remainder should be used. I wand some flags (version, configuration) to be separate and exclusive to subcommands. And the usage is not ambiguous.
msg369333 - (view) Author: Shani Armon (Shani Armon) * Date: 2020-05-19 10:59
Bumping, since no reply was made to my previous comment. If this is not relevant at all can this be closed or marked as such, so that it may be raised in python-dev?
msg378833 - (view) Author: Tal Einat (taleinat) * (Python committer) Date: 2020-10-17 20:49
I suggest bringing this up for discussion on Python-Ideas.
msg378845 - (view) Author: paul j3 (paul.j3) * (Python triager) Date: 2020-10-18 01:48
A more recent issue shows that the use of a '*' positional in a multually_exclusive_group is poorly understood and documented.  

https://bugs.python.org/issue41854

That's part of why I am not enthusiastic about extending this to include REMAINDER.  

And on rereading Shani's posts, I realize I don't understand what this has to do with subcommands.  Is this the 'add_subparsers' mechanism, or just the idea of using a trailing part of sys.argv as input to another parser or script?

I think discussion of this topic can only proceed with some concrete examples, and may be even a proposed code change (not necessarily a formal patch or pull request).
History
Date User Action Args
2022-04-11 14:59:30adminsetgithub: 84689
2020-10-18 01:48:44paul.j3setmessages: + msg378845
2020-10-17 20:49:28taleinatsetnosy: + taleinat
messages: + msg378833
2020-05-19 10:59:25Shani Armonsetmessages: + msg369333
2020-05-07 06:23:37Shani Armonsetmessages: + msg368323
2020-05-06 17:11:01Shani Armonsetmessages: + msg368284
2020-05-06 17:02:22paul.j3setmessages: + msg368282
2020-05-06 05:34:49Shani Armonsetmessages: + msg368227
2020-05-05 23:52:02paul.j3setmessages: + msg368213
2020-05-05 23:49:31paul.j3setnosy: + paul.j3
2020-05-05 11:27:33Shani Armonsetkeywords: + patch
stage: patch review
pull_requests: + pull_request19233
2020-05-05 10:30:44Shani Armoncreate