You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
In argparse, allow REMAINDER(...) arguments in a mutually exclusive group #84689
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.
shaniarmon commented on May 6, 2020
shaniarmonmannequin
MannequinAuthor
More actions
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)
paulj3 commented on May 6, 2020
paulj3mannequin
Mannequin
More actions
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.
shaniarmon commented on May 6, 2020
shaniarmonmannequin
MannequinAuthor
More actions
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
shaniarmon commented on May 7, 2020
shaniarmonmannequin
MannequinAuthor
More actions
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.
shaniarmon commented on May 19, 2020
shaniarmonmannequin
MannequinAuthor
More actions
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?
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).
Activity
shaniarmon commentedon May 5, 2020
Options specified with the REMAINDER nargs should be treated as optional.
And an empty list should be treated as default.
paulj3 commentedon May 5, 2020
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.
shaniarmon commentedon May 6, 2020
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)
paulj3 commentedon May 6, 2020
A flagged argument with REMAINDER works just fine in a mutually exclusive group.
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.
shaniarmon commentedon May 6, 2020
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
shaniarmon commentedon May 7, 2020
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.
shaniarmon commentedon May 19, 2020
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?
taleinat commentedon Oct 17, 2020
I suggest bringing this up for discussion on Python-Ideas.
paulj3 commentedon Oct 18, 2020
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).
serhiy-storchaka commentedon Sep 24, 2024
Done in #124307.
An empty list is now treated as default for REMAINDER. Done in #124306.
Is it what you wanted, @shaniarmon? There are no examples or tests, so I am not sure.