argparse not handling abbreviations in subparser properly

Question

(Run on python 3.6.0)

TL;DR

Usage: prog.py {caesar | vigenere} [key]

parser = argparse.ArgumentParser()
subp = parser.add_subparsers()
caesar = subp.add_parser("caesar", aliases=["c"], allow_abbrev=True)
args = parser.parse_args()
$ python prog.py caes 123
prog.py: error: invalid choice: 'caes' (choose from 'caesar', 'c')

Why is the subparser abbreviation invalid even with allow_abbrev=True?

---

LONG VER

Basically, having an issue getting argparse to accept abbreviated subparsers names/aliases.

Here's the code:

Usage: prog.py [caesar] [key]

import sys, argparse

def main(argv):
parser = argparse.ArgumentParser
         (description="runs text through X cipher")
subp = parser.add_subparsers\
         (help="sub-command help")

#<ArgumentParser object>
caesar = subp.add_parser\
         ("caesar", aliases=["c"], allow_abbrev=True)
caesar.add_argument\
         ("key", metavar = "key (any integer)",\
          type = int, default = 0)


args = parser.parse_args()
print(caesar)

if __name__ == "__main__":
sys.argv = list(str(c).lower() for c in sys.argv[0:])
main(sys.argv)

So from the code above, it should be expected that any of the following should be accepted:

- "Caesar" or "caesar"
- "C" or "c" 
- Any abbreviation in between "c" and "caesar" 

So here's the problem:

This works: $ python prog.py c 123 O

This gives an error: $ python prog.py caes 123 X

prog.py: error: invalid choice: 'cae' (choose from 'caesar', 'c')

Now here's the confusing part.

According to the argparse doc:

ArgumentParser supports the creation of such sub-commands with the add_subparsers() method. The add_subparsers() method is normally called with no arguments and returns a special action object. This object has a single method, add_parser(), which takes a command name and any ArgumentParser constructor arguments, and returns an ArgumentParser object that can be modified as usual.

1. okay, so any object created with add_subparser() can create its own ArgumentParser objectwith object.add_parser() right?

2. ...which means this newly created ArgumentParser object should be able to accept any ArgumentParser arguments yeah?

ArgumentParser definition:

class 
argparse.ArgumentParser(
prog=None, usage=None, 
description=None, epilog=None, 
parents=[],formatter_class=argparse.HelpFormatter, 
prefix_chars='-',fromfile_prefix_chars=None, 
argument_default=None,conflict_handler='error', 
add_help=True, allow_abbrev=True)

Create a new ArgumentParser object. All parameters should be passed as keyword arguments. Each parameter has its own more detailed description below, but in short they are:

allow_abbrev - Allows long options to be abbreviated if the abbreviation is unambiguous.

(default: True)

Changed in version 3.5: allow_abbrev parameter was added.

(this was on python 3.6.0)

---

Thanks in advance, guys

Answer 1

A patch to allow abbreviations of the subparser names was implemented, but then withdrawn when it proved to be buggy:

Issue 12713: allow abbreviation of sub commands by users

Allowing users to turn off abbreviations for long options is a different issue, handled in

Issue 14910: argparse: disable abbreviation

Two different parts of the code.

allow_abbrev - Allows long options to be abbreviated if the abbreviation is unambiguous.

A long option is created with:

caesar.add_argument('-f','--foobar')

With the default allow_abbrev value, this would work with '-f', '--foo', and '--foobar'. The long_option in this case is '--foobar'. With it False, '--foo' would not work.

It's the main parser that decides whether c or caesar or cae are valid subparser commands (via subp, the special action object created by parser.add_subparsers). This behaves more like a positional with choices.

parser.add_argument('foo', choices = ['c', 'caesar'])

Answer 2

The error I'm getting is this:

usage: [-h] {caesar,c} ...
: error: unrecognized arguments: a e s

Hinting that abbreviations are supposed to be composable in the sense that two different abbreviations "c" and "a" can be referenced by passing ca.

What is it that should really happen there? ca is both a combination between the c and the (non-existing) a short form, as well as an abbreviation. Which should the parser prefer? Therefore this question had to be resolved explicitly when the library was designed: For predictability, you just cannot have both.

That being said, maybe you can tweak the result by passing conflict_handler='resolve'? https://docs.python.org/3/library/argparse.html#allow-abbrev