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.

Advertising

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