paul j3 added the comment:
Proposed patches like this are supposed to be generated against the current
development version (3.5...), especially if they are 'enhancements' (as opposed
to bugs). But there isn't much of a difference in argparse between 2.7+ and
3.4+ (except one nested yield expression).
Tests are in 'lib/test/...'
argparse does implement the '--' syntax. That is, anything after it is
understood to be positional, regardless of its prefix characters. But before
that, optionals and positionals can be freely mixed (within limits).
I agree that '--foo=one two' looks a lot more like an unknown optional than the
test case 'a badger'. Strings with '=' are tested earlier in _parse_optional.
A fix that passes test_argparse.py and your example is:
if '=' in arg_string:
option_string, explicit_arg = arg_string.split('=', 1)
if option_string in self._option_string_actions:
action = self._option_string_actions[option_string]
return action, option_string, explicit_arg
else: # added for unrecognized
return None, option_string, explicit_arg
# or return None, arg_string, None
But the '=' case is also tested in the following line:
option_tuples = self._get_option_tuples(arg_string)
The obvious difference is that _get_option_tuples handles abbreviations.
I wonder if the two can be refined to reduce the duplication, and handler your
case as well.
There are other bug issues dealing with multiple '--', the mixing of optionals
and positionals, and controlling whether abbreviations are allowed or not. I
don't recall any others dealing with strings that contain '=' or space.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue22433>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
