Message159528
| Author | loewis |
|---|---|
| Recipients | ezio.melotti, kennyluck, loewis, serhiy.storchaka, vstinner |
| Date | 2012-04-28.17:09:37 |
| SpamBayes Score | -1.0 |
| Marked as misclassified | Yes |
| Message-id | <1335632978.32.0.315657330558.issue13916@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I see. The proper reaction for a codec that can't handle a certain error then is to raise the original exception. I'm -1 on raising LookupError when trying to find the error handler - this would suggest that the error handler does not exist, which is not true. As for simplifying the implementation: it might be reasonable to special-case surrogatepass inside the individual codecs, rather than looking up the error handler. Then the error handler could just be identical to "strict", except that UTF-8, UTF-16, and UTF-32 individually special-case this error handler in their encoders and decoders. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2012-04-28 17:09:38 | loewis | set | recipients: + loewis, vstinner, ezio.melotti, kennyluck, serhiy.storchaka |
| 2012-04-28 17:09:38 | loewis | set | messageid: <1335632978.32.0.315657330558.issue13916@psf.upfronthosting.co.za> |
| 2012-04-28 17:09:37 | loewis | link | issue13916 messages |
| 2012-04-28 17:09:37 | loewis | create | |