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
