Argparse: Explicit default required arguments with add_mutually_exclusive_group are rejected

[keith]

BPO	43220
Nosy	@rhettinger, @keith
PRs	bpo-43220: Accept explicit default args in required groups #24526

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-02-14.06:34:45.098>
labels = ['3.8', 'library', '3.9', '3.10']
title = 'Argparse: Explicit default required arguments with add_mutually_exclusive_group are rejected'
updated_at = <Date 2021-05-12.05:00:45.027>
user = 'https://github.com/keith'

bugs.python.org fields:

activity = <Date 2021-05-12.05:00:45.027>
actor = 'rhettinger'
assignee = 'paul.j3'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-02-14.06:34:45.098>
creator = 'keith'
dependencies = []
files = []
hgrepos = []
issue_num = 43220
keywords = ['patch']
message_count = 5.0
messages = ['386934', '386959', '390398', '390406', '390443']
nosy_count = 3.0
nosy_names = ['rhettinger', 'paul.j3', 'keith']
pr_nums = ['24526']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue43220'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[keith]

With this code:

import argparse

parser = argparse.ArgumentParser()
group = parser.add_mutually_exclusive_group(required=True)
group.add_argument("--foo", default="1")
group.add_argument("--bar")
args = parser.parse_args()
print(args)

When you explicitly pass --foo 1, it is treated as if no argument was passed:

% python3 /tmp/bug.py --foo 1
usage: bug.py [-h] (--foo FOO | --bar BAR)
bug.py: error: one of the arguments --foo --bar is required

I can't tell if this behavior is intentional, but it was surprising to me. It also seems to be somewhat based on the length of the default string. For example on my macOS machine if I change the default to longerstring it does not have this issue.

[keith]

Here's an example outside of argparse showing this is caused by the is comparison with interned string:

import sys

short_string = sys.argv[1]
short_default = '1'
long_string = sys.argv[2]
long_default = 'not-interned'

print(f"short comparisons: id1: {id(short_default)} id2: {id(short_string)}, eq: {short_default == short_string}, is: {short_default is short_string}")
print(f"long comparisons: id1: {id(long_default)} id2: {id(long_string)}, eq: {long_default == long_string}, is: {long_default is long_string}")

% ./python.exe /tmp/foo.py 1 not-interned
short comparisons: id1: 4523386416 id2: 4523386416, eq: True, is: True
long comparisons: id1: 4524440064 id2: 4523395296, eq: True, is: False

[keith]

Would someone be able to review this change?

[rhettinger]

I'll review this but it may take a little while to get to it.

[paulj3]

An overlapping issue

https://bugs.python.org/issue18943
argparse: default args in mutually exclusive groups

That issue shows that this problem arises with small integers as well (<257), which in cpython have unique ids. It's an implementation detail, pypy for example does not have this issue.

The whole purpose of this extra default testing is to allow '?/*' positionals in mutually_exclusive_groups.

The patch I proposed in 2013 is basically the same thing, except I called the new flag variable 'using_default'.

We should review the discussion in that issue to see if it raises any additional issues or concerns.

[serhiy-storchaka]

Closed as a duplicate of #63143.