New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User input to argparse raises Index_Error: "-a=" on a 'store_true' action #80448
Comments
Test case: parser = argparse.ArgumentParser()
parser.add_argument("-a", action="store_true")
args = parser.parse_args("-a=".split()) raises an Index_Error, which is not caught by the argparse error mechanism. This is an unusual case, the coincidence of several user errors - 'store_true' which shouldn't take an argument and a short optional with a bare =. So it's unlikely to occur. Still, argparse shouldn't ever respond to a command line value with an uncaught error. The traceback shows that it occurs during the handling of the explicit_arg in consume_optional. Traceback (most recent call last):
File "argparseRaiseIndexError.py", line 5, in <module>
args = parser.parse_args("-a=".split())
File "/usr/lib/python3.6/argparse.py", line 1743, in parse_args
args, argv = self.parse_known_args(args, namespace)
File "/usr/lib/python3.6/argparse.py", line 1775, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
File "/usr/lib/python3.6/argparse.py", line 1981, in _parse_known_args
start_index = consume_optional(start_index)
File "/usr/lib/python3.6/argparse.py", line 1881, in consume_optional
option_string = char + explicit_arg[0]
IndexError: string index out of range The issue was raised in a Stackoverflow question, where I and the poster explore why it occurs, and possible fixes. https://stackoverflow.com/questions/54662609/python-argparse-indexerror-for-passing-a |
I do something such as: thos code code jump in 1903, and the explicit_arg's value is: 'b=' 1901 action_tuples.append((action, [], option_string)) IMHO, we should judge this explicit_arg's value before jump this judgment statement. |
Adding a judgment of explicit_args in judgment statement in the patch. |
FWIW, raising an uncaught exception isn't what we normally consider a "crash". We typically save that designation for segfaults. Ideally, a good patch/pr will also have tests. Also, given the rarity of the exception, I would be reserved about backporting, keeping it to 3.8 and 3.9. |
Thanks, Raymond. This patch not a formal patch, just show what i want to do. if everything agree this behavior, I would add a normal PR. |
Why did you switch back to "crash"? |
oh, sorry, pls ignore it. I misunderstand your opinion. |
Co-authored-by: Rémi Lapeyre <remi.lapeyre@henki.fr> Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
(cherry picked from commit e02cc6d) Co-authored-by: Hai Shi <shihai1992@gmail.com> Co-authored-by: Rémi Lapeyre <remi.lapeyre@henki.fr> Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
(cherry picked from commit e02cc6d) Co-authored-by: Hai Shi <shihai1992@gmail.com> Co-authored-by: Rémi Lapeyre <remi.lapeyre@henki.fr> Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com> Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
Looks like this has been merged and backported, thanks! |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: