[issue37348] add _PyUnicode_FROM_ASCII macro

Change by Inada Naoki : -- pull_requests: +14097 pull_request: https://github.com/python/cpython/pull/14273 ___ Python tracker ___ _

[issue37348] add _PyUnicode_FROM_ASCII macro

Serhiy Storchaka added the comment: Most of changes are in not performance sensitive code. I do not think there is a benefit of using new macro there. If PyUnicode_FromString() is slow I prefer to optimize it instead of adding yet one esoteric private function for internal needs. In case of

[issue37348] add _PyUnicode_FROM_ASCII macro

Inada Naoki added the comment: Should we make these APIs public? * rename `_PyUnicode_FromASCII` to `PyUnicode_FromASCIIAndSize`. * add `PyUnicode_FromASCII` as static inline function (without ABI). * add `#define _PyUnicode_FromASCII PyUnicode_FromASCIIAndSize` for source code compatibility.

[issue37348] add _PyUnicode_FROM_ASCII macro

Inada Naoki added the comment: I confirmed at least one measurable speedup: ./python -m pyperf timeit -s 'd={}' -- 'repr(d)' FromString: Mean +- std dev: 157 ns +- 3 ns FROM_ASCII: Mean +- std dev: 132 ns +- 3 ns >>> (157-132)/157 0.1592356687898089 -- _

[issue37348] add _PyUnicode_FROM_ASCII macro

STINNER Victor added the comment: > #define _PyUnicode_FROM_ASCII(s) _PyUnicode_FromASCII((s), strlen(s)) LGTM. -- nosy: +vstinner ___ Python tracker ___

[issue37348] add _PyUnicode_FROM_ASCII macro

Change by Inada Naoki : -- keywords: +patch pull_requests: +14091 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14264 ___ Python tracker ___

[issue37348] add _PyUnicode_FROM_ASCII macro

New submission from Inada Naoki : _PyUnicode_FromASCII(s, len) is faster than PyUnicode_FromString(s) because PyUnicode_FromString() uses temporary _PyUnicodeWriter to support UTF-8. But _PyUnicode_FromASCII("hello", strlen("hello"))` is not as easy as `PyUnicode_FromString("hello")`. _PyUni