RetroSearch Browse

Wed Dec 14 09:31:40 CET 2011 · https://mail.python.org/pipermail/python-dev/2011-December/114972.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-December/114972.html below:

[Python-Dev] PyUnicodeObject / PyASCIIObject questions