This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: argparse: creating an already defined subparsers does not raises an exception
Type: enhancement Stage:
Components: Library (Lib) Versions: Python 3.11
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: bethard, bradengroom, eacb, iritkatriel, r.david.murray
Priority: normal Keywords: patch

Created on 2012-05-19 12:27 by eacb, last changed 2022-04-11 14:57 by admin.

Files
File name Uploaded Description Edit
argparse_no_dup_subparsers.diff eacb, 2012-05-19 12:27 review
Pull Requests
URL Status Linked Edit
PR 10159 open bradengroom, 2018-10-28 00:15
PR 10159 open bradengroom, 2018-10-28 00:15
PR 10159 open bradengroom, 2018-10-28 00:15
Messages (5)
msg161112 - (view) Author: Étienne Buira (eacb) * Date: 2012-05-19 12:27
With this patch, it raises an ArgumentException, instead of overwriting previous subparser without notice.

Regards.
msg161359 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-05-22 14:51
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.
msg166087 - (view) Author: Steven Bethard (bethard) * (Python committer) Date: 2012-07-21 22:29
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.
msg328667 - (view) Author: Braden Groom (bradengroom) * Date: 2018-10-28 00:17
https://github.com/python/cpython/pull/10159
msg407555 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2021-12-02 23:11
The open patch deprecates overriding the parser with add_parser, but it does not add the new set_parser method that Steven suggested.
History
Date User Action Args
2022-04-11 14:57:30adminsetgithub: 59061
2021-12-02 23:11:09iritkatrielsetversions: + Python 3.11, - Python 3.3
nosy: + iritkatriel

messages: + msg407555

type: enhancement
stage: patch review ->
2018-10-28 00:18:00bradengroomsetnosy: + bradengroom
messages: + msg328667
2018-10-28 00:15:43bradengroomsetstage: patch review
pull_requests: + pull_request9483
2018-10-28 00:15:39bradengroomsetstage: (no value)
pull_requests: + pull_request9482
2018-10-28 00:15:35bradengroomsetstage: (no value)
pull_requests: + pull_request9481
2012-07-21 22:29:28bethardsetmessages: + msg166087
2012-05-22 14:51:13r.david.murraysetnosy: + r.david.murray, bethard

messages: + msg161359
versions: - Python 2.6, Python 3.1, Python 2.7, Python 3.2, Python 3.4
2012-05-19 12:27:50eacbcreate