Steven Bethard <steven.beth...@gmail.com> added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14856> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com