/Lib/argparse.py incorrect argument parser

[Tony10401]

Bug report

The parser allows multiple options for an optional argument in a subcommand, if you add 2 for example: -n | --name, and then you call it with a single "-" -name "test_name" it will not throw an error nor parse the value correctly, but it will parse it as if you passed -n with 'ame' value (see code example below).

Your environment

$ python --version
Python 3.9.6


$ sysname
x86-64_linux_4.12_ImageSLES12SP5

Code example:

I copied this code from argparse documentation and just added -n|--name to show the behavior

import argparse


def foo(args, leftovers):
    print(args, leftovers)


# create the top-level parser
parser = argparse.ArgumentParser()
subparsers = parser.add_subparsers(required=True)

# create the parser for the "foo" command
parser_foo = subparsers.add_parser('foo')
parser_foo.add_argument('-n', '--name', type=str, default=1)
parser_foo.add_argument('y', type=float)
parser_foo.set_defaults(func=foo)


# parse the args and call whatever function was selected
args, leftovers = parser.parse_known_args()
args.func(args, leftovers)

And then if we run this code we will see that it is not parsing the arguments correctly:

$ python test.py foo 2.0 -name 1
Namespace(name='ame', y=2.0, func=<function foo at 0x2aaaac0b2c10>) ['1']

[ericvsmith]

You need to pass --name 1 on the command line, with two dashes. Or, -n 1, if you want to use the short form. You can't use a single dash unless you're using the short form.

[hpaulj]

That's normal behavior for a short option flag, '-n'. You didn't need subparsers to demonstrate it. I'd vote to close this as npt-a-bug.

[Tony10401]

I know the normal would be to pass either --name 1 or -n 1. The problem is that if the user makes a mistake and passes -name 1 I would expect the parser to error saying that is not a valid option (because it is not), but instead it will succeed and take it as if the user passed -n ame and I think this is indeed a bug because it is not even taking the value the user passed and it could cause some wrong behavior on the CLI.

[ericvsmith]

I think you're asking too much of the parser. But maybe someone has a way of adding that logic to the parser.

[hpaulj]

Under option value syntax that argparse docs say

For short options (options only one character long), the option and its value can be concatenated:

In your example '-n' is the short option. 'ame' is the concatenated value. You may have intended it to be parsed as '--name 1' or even '--name=1'. Because the '-n' matched a short option, the parser did not look at fhe following '1'. That string was handled in a separate pass (as positional or unrecognized).

When allow_abbrev was first added it disabled this short-option concatenation. We had to make a further patch to restore that behavior. This kind of short concatenation has a long history in argparse and UNIX parsers.

argparse has to strike a balance between catching possible errors, and assuming the end user knows what he wants. In between it's the programmer's responsibility to anticpate (even if it is after fact) likely mistakes, and adjust the parser setup accordingly.

[Tony10401]

Alright, thanks guys for the help and information.
Appreciate it.