#! /usr/bin/env python3
import argparse

parser = argparse.ArgumentParser(allow_abbrev=True)
parser.add_argument('-v', '--verbose', action='count')
print(parser.parse_args(['-vv']))

parser = argparse.ArgumentParser(allow_abbrev=False)
parser.add_argument('-v', '--verbose', action='count')
print(parser.parse_args(['-vv']))

Observed Output:
Namespace(verbose=2)
usage: test.py [-h] [-v]
test.py: error: unrecognized arguments: -vv

Expected Output:
Namespace(verbose=2)
Namespace(verbose=2)

This is a side effect introduced by 99302634d756. You have to set allow_abbrev to True to make such match succeed. I think this is a bug.

After some research I suggest to document this behaviour that allow_abbrev=False will suspend option prefix matching. Simply fixing the count action behaviour is not enough since it also prevents you from creating custom actions that want to use option prefix matching. What's your advice berker?

I think the allow_abbrev option should be orthogonal on how short options are parsed. I am using parse_known_args() to forward the unrecognized args to another program, therefore allow_abbrev=False is essential.

There is a special handling for short options in the consume_optional and _get_option_tuples to allow them being concatenated with one dash, as commonly done with short options (eg. "tar -czf file"). I interpret allow_abbrev as an option to avoid matching non-exiting options that should be forwarded to the other program; '-vv' is an existing option with the same meaning as '-v -v'.

This would also mean that parse_known_args(['-vz']) (where '-v' is a registered argument, but '-z' is not) matches '-v' and returns '-z' as unknown argument; but I don't know whether you want to go that far. It is difficult to interpret whether '-verify' should mean '-v -e -r -i -f -y' or '--verify' (but this is why there are double-dash options), especially when the first letter is not a registered short option.

I agree with you. But right now, it seems parsing short options and allow_abbrev both rely on the same logic. If you turn off allow_abbrev, short options parsing also disabled. Separating them seems nontrivial.

It's been 2 years since I worked on this patch. In the issue discussion http://bugs.python.org/issue14910 there was no mention of short v long options. The unit tests only look at longs.

The result is that with the abbrev off, it disables all use of combined shorts, not just the count. Not only if '-vv' disabled, so is '-vz', '-vz1', '-v -z1'.

We should have discussed that issue.

I can imagine modifying the

    if self.allow_abbrev:

to something like

    if self.allow_abbrev or <argstring has only one dash>:
        <search for abbreviations>

But even if we don't go that far, we should add a documentation note.

Someone needs to take the current argparse.py, set the default value of this parameter to False, and run the unittest file. This should turn up this case, and possibly others that fail when abbreviations are turned off. Then we have to debate whether such failures are acceptable or not.

When we say 'disable abbreviations' do we mean, all abbreviations, or just a subset?

Sad to see this still wasn't fixed. The abbreviation "feature" creates ambiguity and room for error and this bug makes the switch unusable for a lot of applications.

#14316 has a fix.

New changeset dffca9e by Miss Islington (bot) (Zac Hatfield-Dodds) in branch 'master':
bpo-26967: fix flag grouping with allow_abbrev=False (GH-14316)
dffca9e

New changeset b1e4d1b by Petr Viktorin (Miss Islington (bot)) in branch '3.8':
bpo-26967: fix flag grouping with allow_abbrev=False (GH-14316) (GH-14759)
b1e4d1b

New changeset 8edfc47 by Kyle Meyer in branch 'master':
bpo-39546: argparse: Honor allow_abbrev=False for specified prefix_chars (GH-18337)
8edfc47

New changeset e412cbb by Miss Islington (bot) in branch '3.8':
[3.8] bpo-39546: argparse: Honor allow_abbrev=False for specified prefix_chars (GH-18337) (GH-18543)
e412cbb