New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add FlagAction to argparse #52784
Comments
From a python-dev email from Neal Becker, copied here so it won't get lost. --foo I've been happily using it, and I think it would be of sufficient general interest to include it with the standard library. |
Are we sure we want three or four ways to spell the same thing? --foo and --no-foo seem a useful couple to me, and --with-foo/--without-foo cater to different use cases. Perhaps it would be ok to have a SwitchAction (or FlagAction) for --thing/--no-hing and one ConfigureAction for the --with[out]-* style. |
I'm looking into making a patch from this for py3k, and have the following observations:
Given feedback that these two decisions seem sane, I'd be happy to produce a patch against recent py3k. |
I think you can go ahead and produce a patch. Don’t start splitting argparse into a package now though, this is a sensible decision IMO but has to be agreed by the maintainer; just add FlagAction and ConfigureAction to argparse for now. |
Some useful tips to make patches: http://www.python.org/dev/patches/ |
I think this should be updated so that nargs=0 is allowed, so that you can only do --foo/--no-foo and don't clutter up the help/interface with --foo [FOO] --no-foo=[FOO] You can do this by adding nargs to the ConfigureAction.__init__ and passing that through to super, and then updating __call__ to check 'if value is None or value == []:' instead of the None. |
I think FlagAction should implement strictly boolean options, that is --foo and --no-foo, without arguments at all. For ConfigureAction, there is a precedent (unless I’m mistaken) in configure, which permits such things: I say we focus on the simple FlagAction for this bug and keep ConfigureAction for another patch. Yaniv: Can you give us a status update? |
On the off chance that someone was waiting for feedback from me, I'll say: (1) A simple boolean --foo/--no-foo action seems useful to me. I would probably call it BooleanOptionalAction rather than FlagAction. (Almost anything could be considered a "flag".) (2) At the moment, argparse doesn't supply any actions, so I don't think we should make a separate namespace for them. If it starts to grow a list of such actions, we can add a separate namespace later. (And given that the name will end with "Action", I think it should be pretty clear without the namespace.) |
I'm sorry but there is no activity since 4 years, so I guess that the feature is not common enough to require a builtin support in argparse. |
@vstinner - I don't think that conclusion is correct, here is a very highly-upvoted answer on SO that indicates a lot of people are still looking for this: https://stackoverflow.com/a/15008806/169947 I myself asked a related (more focused?) question where I was directed here: https://stackoverflow.com/q/53937481/169947 I'm guessing the right thing to do now would be refocus the merge request in a new ticket - is this still the right tracker? |
Let me highlight something about https://stackoverflow.com/a/15008806/169947 The original question was how to implement an Action that accepts 'True' or 'False' as an argument. Users often try https://bugs.python.org/issue14392 My answer in that SO question is https://stackoverflow.com/a/19233287/901925 ---- @mgilson's answer proposes a '--foo', '--no-foo' alternative. That is in line with this bug/issue. parser.add_argument('--feature', dest='feature', action='store_true')
parser.add_argument('--no-feature', dest='feature', action='store_false')
parser.set_defaults(feature=True) So the question here is whether mgilson's simple answer is enough, or do we need to add Eric's ConfigureAction class? On a casual reading the patch proposed here shouldn't have backward compatibility issues, since it is an addon class, and doesn't modify existing classes. But it lacks tests and documentation. Documentation for argparse is a tough issue. While advanced users want more features and more documented details, most of the SO questions come from beginners, who's eyes glaze over when they read the existing documentation. |
Yes, this is the correct bug tracker. And note that this code isn't mine, I just posted it here so it wouldn't be lost. It looks like the original message was from https://mail.python.org/pipermail/python-dev/2010-April/099704.html |
Thanks, Paul and Eric, for your very quick replies. You're quite correct, the original question in https://stackoverflow.com/a/15008806/169947 is indeed hoping for By contrast, with For @mgilson's proposal, I think the main thing I find unsatisfactory (besides the fact that it takes 3 lines to define, and I'll have to come back to that SO answer every time to make sure I get them right...) is that the parser.add_argument('--foo', dest='foo', help="Do foo", action='store_true')
parser.add_argument('--no-foo', dest='foo', help="Don't foo", action='store_false')
parser.set_defaults(foo=True) we get the following --help text (when using ArgumentDefaultsHelpFormatter):
and that last line seems to be a contradiction, or at least very confusing. The only alternative I see is to turn off ArgumentDefaultsHelpFormatter, but I think the defaults are generally helpful information for the user. To fix that --help issue seems to require quite a bit more complicated registration of arguments, so it's probably not going to happen in most people's scripts. I should be clear: I haven't vetted the As for documentation - I had poked around in the code a bit and seen the |
I reopen the issue since it seems like there are people requesting the feature. (I also removed myself from the issue, I'm not interested to implement it.) |
I would like to try and implement the change. I will open a PR shortly. |
I made a first proposal for this feature in PR 11478, I had to adapt argparse.Action to customize how the action is represented in the usage string by adding a format_usage() method that would default to the current behavior if not overridden. Other methods to do this may be better but I did not find them. |
I am also interested by this feature. |
I have merged the PR 11478 and this feature will be included into 3.9. Thank you for your proposal of Remi and thank you to Eric for the idea of this feature. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: