Message346273
| Author | serhiy.storchaka |
|---|
| Recipients | RalfM, ezio.melotti, methane, roufique7, serhiy.storchaka, vstinner, xtreak |
|---|
| Date | 2019-06-22.10:11:04 |
|---|
| SpamBayes Score | -1.0 |
|---|
| Marked as misclassified | Yes |
|---|
| Message-id | <1561198265.14.0.141412799426.issue24214@roundup.psfhosted.org> |
|---|
| In-reply-to | |
|---|
| Content |
|---|
Victor, I think you misunderstood the issue. The problem is not that a decoding error is raised. The problem is that the incremental decoder no longer raises where it raised before.I think that both behavior may be correct, and that it is better to not rely on ability of the incremental decoder with final=False to detect an invalid encoded data, but I see now that it is possible to fix for the original issue more carefully, without changing that behavior.PR 14304 does this.It also change the UTF-16 incremental decoder with the surrogatepass error handler to return a non-empty data when decode a low surrogate with final=False. It is not necessary, but it makes all UTF-* decoders consistent and makes tests simpler. |
|