[issue26394] Have argparse provide ability to require a fallback value be present
Michael Herold added the comment: Yes, a fallback hook at the end of parsing would have to be placed before the 'required' testing, not after as in my 'group' testing. Just to clarify: Would you suggest that a fallback call returns the parsed value (i.e. the fallback calls the action or alike) or `take_action` is called on fallback values after all the other calls are done? I will try to look into your hook system in detail. Maybe you are right and the ideas can be combined nicely. > I still haven't absorbed why this patch is superior to the > ConfigArgParse approach, or chaining dictionary values after parsing. Problems with ConfigArgParse I found: It ignores config and env vars completely if "--" is used on the command line. Implementing positional arguments supplied via config or env var is impossible. Chaining dictionary would require that all arguments are optional. I think that the "make everything optional" approach bypasses to many features of argparse. > I'd also suggest following its example in published this enhancement > in your own repository and pypi. Thanks for the suggestion. I will surely consider this. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26394] Have argparse provide ability to require a fallback value be present
Michael Herold added the comment: Thanks so much for looking into my patch! Let me start by outlining that I don't understand how your alternate solutions are coping with the key problem. You are assuming that you get a populated Namespace object. However, `_parse_known_args` is exiting if required arguments are missing. Hence, late hooks or working with Namespaces is just too late. I was thinking about adding an option that suppresses required argument errors, but this again implies that parts of the logic have to be reimplemented outside of argparse. Let me remind you of ConfigArgParse again. It constructs an argument string from configs etc. and appends it to sys.argv before calling argparse. Surprise: This is not rock solid and limits the capabilities. There is almost no other way to attach these functionalities to argparse. The `actions_with_values` dict should actually be ordered. My bad. With an ordered dict, the order can only be changed if a fallback is present. The desired behaviour has to be defined in this context. However, without fallbacks the order is identical with an ordered dict. I totally get that backward compatibility is a delicate thing in this context. Unit tests: All passing, up to action='append'. This is related to a design decision to be made for fallbacks in case of multiply supplied arguments. Number of arguments for fallbacks: This part was blind guessing and it worked for my simple test cases. I really didn't dive into this regex part in detail. At least extensive unit tests for fallbacks are required anyways. Values and objects instead of strings: Think there are two aspects. 1. That example.py had to handle bools explicitly is a design decision. How bools can be supplied in configs or env vars should not be hard coded in argparse. This also applies for my [x,y] list syntax etc. 2. Supplying actual objects/values as fallback makes sense. The current implementation (with my example) is such, that you can supply the arguments in the same form as on the command line. If you have interpreted this information already (say, fallback returns `true` instead of `[]`), you don't want the returned fallback to be handled in the usual way [number of arguments differs (it's not even a list), action gets unexpected input]. Maybe the fallback can indicate that by returning an argparse.FinalValue() object or what ever. Subparsers: Yeah, big unknown. But my intuition is, that this can be solved nicely. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26394] Have argparse provide ability to require a fallback value be present
Changes by Michael Herold <qua...@hemio.de>: Added file: http://bugs.python.org/file42062/example.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26394] Have argparse provide ability to require a fallback value be present
Michael Herold added the comment: I have prepared a working patch to sketch how this could be implemented. A small example (example.py) shows how this feature can be used to implement a fallback to environment variables. This patch allows Currying of positional arguments (i.e. you can give position 2 via fallback and provide position 1 via the command line). However, I think this might be too confusing and implicit. Please let me know whether I should prepare a proper patch. -- keywords: +patch Added file: http://bugs.python.org/file42061/argparse-wip-1.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26394] Have argparse provide ability to require a fallback value be present
Michael Herold added the comment: Thank you for clarifying my request. Callables sound like a great solution to me! Looks like the fallback should be called in `take_action()` if argument_values is "empty" (None?). Per default it should be transparent to an `Action` if the values are based on a fallback call. However, it might be useful to call `Action` with two additional parameters like `commandline_values` and `fallback_values` such that a (custom) action 'append_with_fallback' can be realized. Calling the fallback each time (required for `fallback_values`) makes it some kind of early called hook for argparse. I am attaching a sketch of what might be a typical use case. I noted that a callable supplied to fallback would usually rely on informations that could be provided as `action.long_option_names` and `action.is_positional` to avoid that this logic is implemented outside of argparse again. Please let me know I can provide any help. -- Added file: http://bugs.python.org/file41984/fallback.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26394] argparse: Add set_values() function to complement set_defaults()
New submission from Michael Herold: argparse has at least three features to set defaults (default=, set_defaults(), argument_default=). However, there is no feature to set the values of arguments. The difference is, that a required argument has to be specified, also if a default value exists. Thus, a clean way to set values from config files or env variables does not exist without making all arguments optional. See for example <http://stackoverflow.com/questions/10551117/setting-options-from-environment-variables-when-using-argparse>, where it becomes clear that no general solution for all actions exists. As a result, people also start to mess around with the args parameter of parse_args(). Even ConfigArgParse (used by Let's Encrypt) seems to fail in doing this properly. So please add a set_values() function, similar to set_defaults(). The predefined value should be treated as if it had been entered on the command line. If the value has also been supplied via the command line, the predefined value is overwritten. -- components: Library (Lib) messages: 260568 nosy: quabla priority: normal severity: normal status: open title: argparse: Add set_values() function to complement set_defaults() type: enhancement versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
