argparse: creating an already defined subparsers does not raises an exception

[eacb]

BPO	14856
Nosy	@bitdancer, @bradengroom, @iritkatriel
PRs	bpo-14856: Deprecate using add_parser() to overwrite an existing subparser #10159 bpo-14856: Deprecate using add_parser() to overwrite an existing subparser #10159 bpo-14856: Deprecate using add_parser() to overwrite an existing subparser #10159
Files	argparse_no_dup_subparsers.diff

^{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 2012-05-19.12:27:50.832>
labels = ['type-feature', 'library', '3.11']
title = 'argparse: creating an already defined subparsers does not raises an exception'
updated_at = <Date 2021-12-02.23:11:09.228>
user = 'https://bugs.python.org/eacb'

bugs.python.org fields:

activity = <Date 2021-12-02.23:11:09.228>
actor = 'iritkatriel'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2012-05-19.12:27:50.832>
creator = 'eacb'
dependencies = []
files = ['25637']
hgrepos = []
issue_num = 14856
keywords = ['patch']
message_count = 5.0
messages = ['161112', '161359', '166087', '328667', '407555']
nosy_count = 5.0
nosy_names = ['bethard', 'r.david.murray', 'eacb', 'bradengroom', 'iritkatriel']
pr_nums = ['10159', '10159', '10159']
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue14856'
versions = ['Python 3.11']

[eacb]

With this patch, it raises an ArgumentException, instead of overwriting previous subparser without notice.

Regards.

[bitdancer]

Thanks for the report and patch.

However, since there is no del_parser method, I'm inclined to think that this is not a bug. That is, the ability to overwrite a previously defined subparser could be considered a feature.

If Steven does consider it a bug, I think it can only be fixed in 3.3, since to do otherwise could needlessly break currently-working programs. If it is not a bug, add_parser's behavior when a parser already exist should be documented.

[bethard]

Yeah, overwriting the existing parser is probably not typically what the user intended.

However, I could see someone doing this if, say, they had a parser designed by another module writer, and they wanted to use it but just change one of the sub-parsers or something like that. But a "set_parser" method would probably make more sense for this use case than "add_parser".

I guess my recommendation is to add a "set_parser" method that replaces the old parser (like "add_parser" does now), and then issue deprecation warnings in "add_parser" if a parser with the given name is present (like the patch does, but with deprecation warnings instead of exceptions).

We could then turn the warnings into errors in a few releases.

[bradengroom]

#10159

[iritkatriel]

The open patch deprecates overriding the parser with add_parser, but it does not add the new set_parser method that Steven suggested.

[serhiy-storchaka]

Adding a parser with a name or an alias that matches an existing parser was forbidden in bpo-39716 (gh-83897).