[issue42973] argparse: mixing optional and positional arguments... not again

Change by Tadek Kijkowski : -- pull_requests: +23190 pull_request: https://github.com/python/cpython/pull/24367 ___ Python tracker ___ _

[issue42973] argparse: mixing optional and positional arguments... not again

Tadek Kijkowski added the comment: > So in the big picture, the purpose of this change is to treat the inputs like > a kind of state-machine. Not necessarily that. Simple parsers should be easy to write, complicated parsers should be _possible_ to write. Users should be able to do whatever t

[issue42973] argparse: mixing optional and positional arguments... not again

Glenn Linderman added the comment: paul j3 said: 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. Th

[issue42973] argparse: mixing optional and positional arguments... not again

paul j3 added the comment: Sometimes patches have unforeseen benefits. My earlier patch for this issue, parse_intermixed_args, has been useful beyond the OP's case. https://stackoverflow.com/questions/50916124/allow-positional-command-line-arguments-with-nargs-to-be-seperated-by-a-flag http

[issue42973] argparse: mixing optional and positional arguments... not again

paul j3 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

[issue42973] argparse: mixing optional and positional arguments... not again

Glenn Linderman added the comment: Yes I think this is a useful enabling step toward enhanced functionality, as is. But I think the learning curve to achieve the enhanced functionality is a bit high for most people, as it requires too much knowledge of argparse internals, so I really look fo

[issue42973] argparse: mixing optional and positional arguments... not again

Tadek Kijkowski added the comment: I went with Paul's suggestion and added nargs='**' instead of greedy, so at this moment this PR doesn't introduce any changes in any public signatures. I'm working on 'capture' actions, but I want that to be a separate PR and a separate issue because - firs

[issue42973] argparse: mixing optional and positional arguments... not again

Tadek Kijkowski added the comment: Paul, > The basic logic of argparse is to accept optionals in any order, and > positionals in strict positional order. 'nargs' allows us to pair any number > of strings with each optional's flag. I started this issue because that was insufficient for my p

[issue42973] argparse: mixing optional and positional arguments... not again

Glenn Linderman added the comment: Paul said: I haven't had a chance to study your longer posts, but it seems to me that the AddFruitAction example could just as well be implemented with parser.add_argument('--color', nargs='*', action='append') with post parsing processing to create th

[issue42973] argparse: mixing optional and positional arguments... not again

Glenn Linderman added the comment: This sounds very good to me. Might also want action='store_capture' for a single positional definition? capture could be a string, or any iterable of strings (tuple comes to mind) capture_once have similar value as capture, but I wonder if the naming would

[issue42973] argparse: mixing optional and positional arguments... not again

paul j3 added the comment: I haven't had a chance to study your longer posts, but it seems to me that the AddFruitAction example could just as well be implemented with parser.add_argument('--color', nargs='*', action='append') with post parsing processing to create the 'fruits' dicts fr

[issue42973] argparse: mixing optional and positional arguments... not again

Tadek Kijkowski added the comment: >> In the docs fruits example, though, I think the input and output are >> inconsistent: you have a brown banana reported as yellow? Yeah, I noticed that and fixed already :) I agree with your ideas. My goal was just to provide bare minimum that would all

[issue42973] argparse: mixing optional and positional arguments... not again

Glenn Linderman added the comment: for more helpful => far more helpful -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue42973] argparse: mixing optional and positional arguments... not again

Glenn Linderman added the comment: OK, I think I see what you are doing here. Thanks for your responses. And probably it is the bare-bones minimum feature that allows user-implementation of "as complex as desired" combinations of optionals and context-sensitive positionals. In the docs frui

[issue42973] argparse: mixing optional and positional arguments... not again

Tadek Kijkowski added the comment: This is, I think, smallest functional example for matching optional parameters with positionals - fruits.py: import argparse DEFAULT_COLOR="plain" class AddFruitAction(argparse.Action): def __call__(self, parser, namespace, values, option_st

[issue42973] argparse: mixing optional and positional arguments... not again

Tadek Kijkowski added the comment: >> Is it up to the special handler of the positional parameter to read and save >> the values of the optional parameters specified so far? Yes, in order to get anything more that just concatenated list of positional parameters, one has to provide specialize

[issue42973] argparse: mixing optional and positional arguments... not again

Glenn Linderman added the comment: On 1/25/2021 12:43 PM, Tadek Kijkowski wrote: > Tadek Kijkowski added the comment: > > I added tests and docs to the PR. How does it look now? Could you send me the docs privately? I'm trying to understand what you are suggesting, without reading the code. I

[issue42973] argparse: mixing optional and positional arguments... not again

Tadek Kijkowski added the comment: I added tests and docs to the PR. How does it look now? -- ___ Python tracker ___ ___ Python-bug

[issue42973] argparse: mixing optional and positional arguments... not again

Change by Glenn Linderman : -- nosy: +v+python ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue42973] argparse: mixing optional and positional arguments... not again

Tadek Kijkowski added the comment: >> I tried to checkout python sources, but even with -depth 1 it took too long >> for my patience and I gave up after 'du -sh .git' showed 2G. Ignore that. I must have been doing something worng. -- ___ Python tr

[issue42973] argparse: mixing optional and positional arguments... not again

Tadek Kijkowski added the comment: >> Your example is incomplete. That is _CustomAction? What namespace does >> your patch produce. >> In your example I'd suggest making '--tracks' a nargs=2 and 'append' option. >> 'choices' would have to be replaced with a either a custom 'type', a custo

[issue42973] argparse: mixing optional and positional arguments... not again

paul j3 added the comment: Your patch is incomplete, without documentation or tests. Your example is incomplete. That is _CustomAction? What namespace does your patch produce. It's been a while since I worked on the intermixed patch, but as I recall the OP was happy with the fix. Also I

[issue42973] argparse: mixing optional and positional arguments... not again

Change by Raymond Hettinger : -- nosy: +paul.j3, r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue42973] argparse: mixing optional and positional arguments... not again

Change by Tadek Kijkowski : -- keywords: +patch pull_requests: +23083 stage: -> patch review pull_request: https://github.com/python/cpython/pull/24259 ___ Python tracker ___

[issue42973] argparse: mixing optional and positional arguments... not again

New submission from Tadek Kijkowski : I have following use case for argparse: ./prog --tracks=80 image1 --tracks=40 image2 --tracks=80 image3 ... I expected that the following parser would be able process that command line: parser = argparse.ArgumentParser() add = parser.add_argument add('--t