Message274222
The "us-ascii" encoding is an alias to the Python ASCII encoding. PyUnicode_AsEncodedString() and PyUnicode_Decode() functions have a fast-path for the "ascii" string, but not for "us-ascii".
Attached patch uses also the fast-path for "us-ascii". It's a more generic change than the issue #27915. The "us-ascii" name is common in the email and xml.etree modules.
Other changes of the patch:
* Rewrite _Py_normalize_encoding() as a C implementation of encodings.normalize_encoding(). For example, " utf-8 " is now normalized to "utf_8". So the fast path is now used for more name variants of the same encoding.
* Avoid strcpy() when encoding is NULL: call directly the UTF-8 codec
* Reorder encodings: UTF-8, ASCII, MBCS, Latin1, UTF-16
* Remove fast-path for UTF-32: seriously, nobody uses this codec. Latin9 is much faster but has no fast-path. |
|
| Date |
User |
Action |
Args |
| 2016-09-02 10:19:34 | vstinner | set | recipients:
+ vstinner, nnnnnn, ezio.melotti, serhiy.storchaka |
| 2016-09-02 10:19:34 | vstinner | set | messageid: <1472811574.16.0.472581628747.issue27938@psf.upfronthosting.co.za> |
| 2016-09-02 10:19:34 | vstinner | link | issue27938 messages |
| 2016-09-02 10:19:33 | vstinner | create | |
|