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

Created on 2012-05-19 12:27 by eacb, last changed 2018-10-28 00:18 by bradengroom.

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 (4)
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
History
Date User Action Args
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