Message166087
| Author |
bethard |
| Recipients |
bethard, eacb, r.david.murray |
| Date |
2012年07月21日.22:29:28 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1342909769.21.0.690189438618.issue14856@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年07月21日 22:29:29 | bethard | set | recipients:
+ bethard, r.david.murray, eacb |
| 2012年07月21日 22:29:29 | bethard | set | messageid: <1342909769.21.0.690189438618.issue14856@psf.upfronthosting.co.za> |
| 2012年07月21日 22:29:28 | bethard | link | issue14856 messages |
| 2012年07月21日 22:29:28 | bethard | create |
|