paul j3 <ajipa...@gmail.com> added the comment:

This is a complicated issue that needs a lot of thought and testing before we 
make any changes.

While all Actions have the 'required' attribute, the programmer can only set it 
for optionals.  _get_positional_kwargs() will raise an error if the programmer 
tries to set it for a positional.  For a positional its value is determined by 
the nargs value.

The distinction between positionals and optionals occurs through out argparse, 
so we shouldn't put much effort (if any) into making their handling more 
uniform.  (The fundamental distinction between the two is whether the 
action.option_strings list is empty or not.)

A fundamental difference in parsing is that an optional's Action is called only 
if the flag is used.  A positional's Action is always called.   

_parse_known_args starts with a list of positionals

    positionals = self._get_positional_actions()

The nested consume_positionals function removes actions from this list.

Earlier versions raised an error at the end of parsing if this list was not 
empty.  In the current version that's been replace by the 'required_actions' 
test (which tests both positionals and optionals).  It was this change over 
that resulted in the bug/feature that subparsers (a positionals Action) are no 
longer required (by default).

Positionals with nargs='?' and '*' pose an extra challenge.  They are, in a 
sense, no longer 'required'.  But they will always be 'seen' because their 
nargs is satisfied by an empty list of values.  But that would overwrite any 
'default' in the Namespace.  So there's the added step in _get_values of 
(re)inserting the action.default.  And it's the handling of that 'default' that 
gives rise to the current issue.

These two positionals can also be used in a mutually_exclusive_group.  To 
handle that 'take_action' has to maintain both the 'seen_actions' set and the  
'seen_non_default_actions' set.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36078>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to