paul j3 <ajipa...@gmail.com> added the comment:
So in the big picture, the purpose of this change is to treat the inputs like a
kind of state-machine.
In the bigger example, the `**` positional values are processed one by one,
using the interspersed optionals to set state parameters.
`args.sources` then ends up as a list of dicts, each of the form:
{'name': 'input3.txt', 'frobnicate': None, 'massage_level': 5}
where 'name' is the positional value, and 'frobnicate' and 'massage_level' are
the latest values (default or user supplied). The optionals can be specified
in any order or repeatedly.
While the proposed change to the core parser is (apparently) minor, it does
occur at the center of the action. That is not the place we want any (new)
bugs or backward incompatibility. And the full implementation requires a new
Action subclass that is quite different from existing ones.
Given how different this is from the normal argparse parsing (and the POSIX
parsing argparse seeks to emulate), I question the wisdom of adding this, in
part or whole, to the stock distribution. It could certainly be published as a
pypi. That already has a number of parsers, some built on argparse, others
stand alone.
I also wonder whether it would be simpler to do this kind of parsing directly
from sys.argv. Just step through that list, consuming the values and flags in
sequence.
Sorry to sound like a wet blanket, but I've seen too many seemingly innocent
patches that caused unforeseen problems down the line.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue42973>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
