Rename PyUnicode_KIND_SIZE ?
Hello, The PyUnicode_KIND_SIZE macro is defined as follows. Its name looks rather mysterious or misleading to me. Could we rename it to something else? (also, is it useful? PEP 393 has added a flurry of new macros to unicodeobject.h and it's getting hard to know which ones are genuinely useful, or well-performing) /* Compute (index * char_size) where char_size is 2 ** (kind - 1). The index is a character index, the result is a size in bytes. See also PyUnicode_CHARACTER_SIZE(). */ #define PyUnicode_KIND_SIZE(kind, index) \ ((Py_ssize_t) ((index) << ((kind) - 1))) Regards Antoine.
Le 06/10/2011 15:52, Antoine Pitrou a écrit :
The PyUnicode_KIND_SIZE macro is defined as follows. Its name looks rather mysterious or misleading to me. Could we rename it to something else?
What do you propose?
also, is it useful?
index << (kind - 1) and index * PyUnicode_CHARACTER_SIZE(str) were used in unicodeobject.c. It's not easy to understand this formula, and it heavily depend on how kind is defined. I wrote a patch to use enum for kind using different values, but the gain was minor so I didn't commit it. We may move it to unicodeobject.c. index * PyUnicode_CHARACTER_SIZE(str) is enough for the public API. (PyUnicode_KIND_SIZE() is also a micro-optimization, it uses shift instead of multiply.)
PEP 393 has added a flurry of new macros to unicodeobject.h and it's getting hard to know which ones are genuinely useful, or well-performing)
Yes, we have to review new functions and macros. Victor
On Thu, 06 Oct 2011 17:52:05 +0200
Victor Stinner
index << (kind - 1) and index * PyUnicode_CHARACTER_SIZE(str) were used in unicodeobject.c. It's not easy to understand this formula
index * PyUnicode_CHARACTER_SIZE(str) is quite easy to understand to me. I find it less cryptic than PyUnicode_KIND_SIZE(kind, index), actually, and I would advocate using the former and removing the latter.
(PyUnicode_KIND_SIZE() is also a micro-optimization, it uses shift instead of multiply.)
I don't know, but I think the compiler should be able to do that for you. Also, I don't think PyUnicode_KIND_SIZE would be used in a critical loop. You would use PyUnicode_READ when doing one-character-at-a-time stuff. Regards Antoine.
(also, is it useful? PEP 393 has added a flurry of new macros to unicodeobject.h and it's getting hard to know which ones are genuinely useful, or well-performing)
Please understand that not all of them have been added by PEP 393 genuinely. Some have only be added by individual committers, and we have to review and revoke those that are not useful. (Of course, some of those that did get added by the PEP may also not be useful). Regards, Martin
participants (3)
-
"Martin v. Löwis" -
Antoine Pitrou -
Victor Stinner