Ken Williams <kena...@gmail.com> added the comment:
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 `--foo TRUE` and `--foo False` etc. to work. Personally I don't like that as much as the GNU-style `--foo` and `--no-foo` technique, because when you let people type `TRUE` or `True` or `T` or `1`, etc., it gets a bit confusing about exactly what is accepted as a true value, what's false, is a zero interpreted as 0 or "0", whether a failure to parse the value as True or False will be reported as an error or not, and so on. The user typically can't really know these answers without reading the actual code, or running it to see what generates an error (or triggers whatever behavior they're looking for), which is certainly not ideal. By contrast, with `--foo` and `--no-foo`, the options are strict and clear. And supplying an argument will trigger a parse failure. 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 `--help` output can't be made clear. With the following specification: 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): --foo Do foo (default: True) --no-foo Don't foo (default: True) 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 `argparse_bool.py` proposal in detail either, so I'm not specifically asking for it to be adopted. Just hoping for a nice resolution to the `--foo` `--no-foo` issue that codifies best-practices in a way that makes it trivial to get nice behavior in scripts. As for documentation - I had poked around in the code a bit and seen the `register` method, but I thought since it wasn't documented, I'd better not use it. Is it for public consumption? If so, I'd say it's better documented than undocumented, even if it provides more info than most people need. My guess is that enough people are probably using it to make it impossible to eliminate, which is a good test for whether something should be documented too. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue8538> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
