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.
| Author | rharris |
|---|---|
| Recipients | amaury.forgeotdarc, rharris |
| Date | 2008年04月17日.19:48:02 |
| SpamBayes Score | 0.035600703 |
| Marked as misclassified | No |
| Message-id | <1208461685.43.0.0784544277887.issue2651@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I think it is important to round-trip for at least two reasons: 1) Consistency. Other built-in exceptions behave this way, why should KeyError be any different? Okay, technically 3 UnicodeErrors don't allow just strings to be passed in (perhaps they should :-); but for common exception classes, they all behave the same way. To quote PEP-20: "Special cases aren't special enough to break the rules" 2) Intuitiveness. Decorating the string with quotes is unexpected; it has already caused at least one bug and could cause more. Ensuring intuitive round-trip behavior is an important enough issue that is explicitly discussed in PEP 327 for the decimal type. Why can't intuitiveness be restored to KeyError in Py3K? |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年04月17日 19:48:05 | rharris | set | spambayes_score: 0.0356007 -> 0.035600703 recipients: + rharris, amaury.forgeotdarc |
| 2008年04月17日 19:48:05 | rharris | set | spambayes_score: 0.0356007 -> 0.0356007 messageid: <1208461685.43.0.0784544277887.issue2651@psf.upfronthosting.co.za> |
| 2008年04月17日 19:48:04 | rharris | link | issue2651 messages |
| 2008年04月17日 19:48:03 | rharris | create | |