argparse: Strange behaviour of positional arguments with `store_true`, `store_false`, or `store_const` action

[kkarbowiak]

Bug report

When store_true, store_false, or store_const is set as an action of positional argument, the behaviour is counterintuitive. Running this small program:

import argparse

parser = argparse.ArgumentParser()
parser.add_argument('pos', action='store_true')
print(parser.parse_args([]))

outputs Namespace(pos=True). Changing last line to print(parser.parse_args(['foo'])) gives an error:

usage: prog.py [-h]
prog.py: error: unrecognized arguments: foo

Your environment

• CPython versions tested on: 3.10.2
• Operating system and architecture: Linux x86-64

Expected behaviour

I believe there is no good reason to allow setting those actions to positional arguments. Trying to do so should result in raising an exception (as is the case when trying to set required).

Linked PRs

• gh-97848: argparse: Disallow misbehaving actions for positional arguments #98367

[rhettinger]

That behavior is weird.

It doesn't seem to have caused problems in practice. If an exception does get added, it should not be backported. Essentially, this is a feature request to provide early warning about an action that doesn't make sense for positional arguments.

[hpaulj]

It's not entirely clear where such a test or warning should be added. add_argument doesn't do a whole lot of testing itself. Based on the absence of prefixchars, it calls _get_positional_kwargs to tweak the args/kwargs mix. Same for optionals. For both, the action is actually created with action = action_class(**kwargs). The action class may be one of the registered subclasses, or a user defined subclass. No one checks whether that 'action_class' is appropriate for optionals or positionals.

This _get_positional_kwargs is used before it looks for the action class.

nargs=0, unless provided by the user, is set by the action_class. The 'store_const' subclasses are distinct in that they use nargs=0. Subclasses like this don't normally test whether they are creating a positional or optional, though I suppose it could test whether the option_strings argument is empty to not (that's how later code distinguishes between the two).

Given this calling structure there isn't a whole lot checking of the kwargs. Wrong or unnecessary kwargs are ignored, or allowed to raise some sort of low level error (such as in the Action subclass). This keeps the overall code simple, without potentially large and complex "checking" routines. It also allows you, the developer, to write custom Action classes without being blocked by some master-parameter-checker.

Also errors like this will arise normally during development and testing. That's when the programmer can easily correct things. What we don't want are un-caught errors during production use. There every error should result in a proper call to self.error, with a message aimed at the final user.

Many of these complaints about add_argument parameters come from developers who are pushing the bounds of what's documented. They want 'store_true' that accept arguments, or use a type that isn't a callable, or use some unrealistic combination of kwargs. These problems can usually be tracked down by matching the error message with the argparse.py code (which is linked in the doc page). It's hard to anticipate this kind of error without imposing a straight-jacket on everyone.

[serhiy-storchaka]

This is a duplicate of #85935. #124839 provides a more general solution that does not depend on the name of the action or how the action is provided (by name or by class).

[Gabrielcarvfer]

How on earth am I supposed to do this now with Python 3.14?

    parser_help = sub_parser.add_parser("help", help="Print a summary of available commands")
    parser_help.add_argument(
        "help", help="Print a summary of available commands", action="store_true", default=False
    )

To get a flag named help=False when anything but cmd help is passed?