[Python-Dev] PyUnicodeObject / PyASCIIObject questions

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