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:
p = argparse.ArgumentParser()
p.add_argument('-a', action='store_true')
p.add_argument('-b', action='store_true')
p.parse_args('-ab='.split())

thos code code jump in 1903, and the explicit_arg's value is: 'b='

1901   action_tuples.append((action, [], option_string))
1902   char = option_string[0]
1903   option_string = char + explicit_arg[0]

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.