Patch tests are added to an existing 'Lib/test/test_argparse.py' file.  I use existing test cases as a pattern any new tests.

---------------------

Your test file runs fine with the patch I proposed for Issue 9334.

---------------------

The argparse code uses '_negative_number_matcher' for 2 purposes

1) to test whether an option_string looks like a negative number, and set the 'self._has_negative_number_optionals' attribute.

    parser.add_argument('-2')
    parser.add_argument('-1.234')

2) to test whether an argument string (an element of sys.argv) looks like one of those option_strings, or is an argument (positional or argument to your '-a').

The 'type' in for your '-a' argument is separate issue.  That is used convert a string to a number, float, complex or what ever, and raise an error it if can't do so.

In your case './test.py -a -1e5' fails because '-1e5' fails the 2nd test, and thus is not recognized as an argument to '-a'. Understanding the details of this requires digging into the logic of the _parse_optional() method.

'./test.py -a-1e5' or './test.py -a=-1e5' work because the number is correctly recognized as an argument.

For issue 9334 I looked at generalizing '_negative_number_matcher' as you did.  But unless you want to use something like:

    parser.add_argument('-1.2e-34')

and set the 'self._has_negative_number_optionals' to '[True]', the matcher doesn't need to be more general.

It's only the test in '_parse_optional()' that needs to be generalized to handle scientific and complex notation.  And for that I figured that wrapping 'complex()' in a 'try' block was just as general and reliable as a complicated 're' pattern.  At least that was my claim in issue 9334, and I haven't gotten feedback on that.

I'd suggest reading the 9334 discussion, and testing that patch.  That patch includes some tests for scientific and complex numbers.

That issue and patch also adds a 'args_default_to_positional' parameter. I wonder if the two changes should be put in separate patches.