[issue22433] Argparse considers unknown optional arguments with spaces as a known positional argument
paul j3
report at bugs.python.org
Mon Sep 22 23:25:09 CEST 2014
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 <report at bugs.python.org>
<http://bugs.python.org/issue22433>
_______________________________________
More information about the Python-bugs-list
mailing list