[Python-Dev] PyUnicodeObject / PyASCIIObject questions (original) (raw)

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 PyUnicodeKind 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