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