paul j3 <ajipa...@gmail.com> added the comment: Oops, I see I already mentioned 9334. Here the parsing sequence is a bit different, and the fix I suggest there would not apply here. But the underlying issue is still there - the parser has, in its first iteration, determined that the '--def' looks like an optional. This first scan focuses on the form, not on possible 'nargs' sequences.
In _parse_known_args() it alternates between 'consume_positionals' and 'consume_optional' In the docs example: '--foo B cmd --arg1 XX ZZ' It finds the '--foo' and parses that as optional, consuming the 'B' Next it finds 'cmd', and so starts to parse positionals. Here is pays attention to the REMAINDER, and thus consumes 'cmd' and the following strings. In other words, once it starts to parse positionals, it can parse as many as match their nargs. The same applies to the 'abc --def' example given at the start of this question. But in the 2nd example, with just the REMAINDER and a ['--def'], it doesn't parse any positionals. The code has this comment: # consume any Positionals preceding the next option There aren't any strings preceding the '--def', so it moves on to parsing this 'optional'. Yes, I know you think it really is a positional, because you know about the REMAINDER nargs, but the code doesn't know this (or at least doesn't check for that possibility. As stressed in 9334, when a dashed string is used in a argument like slot, there's an inherent ambiguity. Should it treat as a (potential) error, or accept the programmer and/or user is going against convention? https://bugs.python.org/issue9334#msg111691 ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17050> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
