[Python-Dev] PyUnicodeObject / PyASCIIObject questions
Victor Stinner
victor.stinner at haypocalc.com
Wed Dec 14 09:31:40 CET 2011
Le mardi 13 décembre 2011 02:09:02 Jim Jewett a écrit :
> (3) I would feel much less nervous if the remaining 4 values of
> PyUnicode_Kind were explicitly reserved, and the macros raised an
> error when they showed up. (Better still would be to allow other
> values, and to have the macros delegate to some attribute on the (sub)
> type object.)
A macro is not supposed to raise an error. In debug mode,
_PyUnicode_CheckConsistency() ensures that the kind is valid and
PyUnicode_KIND() fails with an assertion error if kind is
PyUnicode_WCHAR_KIND.
Python cannot create a string with a kind different than PyUnicode_1BYTE_KIND,
PyUnicode_2BYTE_KIND or PyUnicode_4BYTE_KIND (the legacy API creates strings
with a temporary PyUnicode_WCHAR_KIND kind, kind quickly replaces by
PyUnicode_READY).
If you write your own extension generating an invalid string, I don't think
that Python can help you. Python cannot check all data, it would be too slow.
If we change something, I would suggest to remove PyUnicode_WCHAR_KIND from
the PyUnicode_Kind, so you can be sure that PyUnicode_KIND() result is an enum
with 3 possible values (PyUnicode_1BYTE_KIND, PyUnicode_2BYTE_KIND or
PyUnicode_4BYTE_KIND). It would help to make quiet the compiler on switch/case
;-)
Victor
More information about the Python-Dev
mailing list