Message162582
| Author |
serhiy.storchaka |
| Recipients |
doerwalter, eric.araujo, lemburg, loewis, serhiy.storchaka |
| Date |
2012年06月10日.10:51:16 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1339325482.18692.11.camel@raxxla> |
| In-reply-to |
<1339292045.07.0.369477598475.issue14850@psf.upfronthosting.co.za> |
| Content |
> What is the use case for passing a string subclass to charmap_decode? Or in other words, how did you stumble upon the bug?
I stumbled upon it, rewriting the charmap decoder (issue14874). Now
charmap decoder processes the two cases -- a more effective case of
string table and a general slower case of general mapping. I proposed a
more optimized case of 256-character UCS2 string (covers all standard
charmap encodings). If processing general strings and maps was
consistent, these cases can be merged. A string subclass is just an
example that illustrates the inconsistency. |
|