"Martin v. Löwis"
martin at v.loewis.de
Wed Nov 23 20:58:23 CET 2011
> In Python 3.2, PyUnicode_Resize() expects a number of Py_UNICODE units,
> whereas Python 3.3 expects a number of characters.
Is that really the case? If the string is not ready (i.e. the kind is
WCHAR_KIND), then it does count Py_UNICODE units, no?
Callers are supposed to call PyUnicode_Resize only while the string is
under construction, i.e. when it is not ready. If they resize it after
it has been readied, changes to the Py_UNICODE representation wouldn't
be reflected in the canonical representation, anyway.
> Should we rename PyUnicode_Resize() in Python 3.3 to avoid surprising bugs?
IIUC (and please correct me if I'm wrong) this issue won't cause memory
corruption: if they specify a new size assuming it's Py_UNICODE units,
but interpreted as code points, then the actual Py_UNICODE buffer can
only be larger than expected - right?
If so, callers could happily play with Py_UNICODE representation. It
won't have the desired effect if the string was ready, but it won't
crash Python, either.
> The easiest solution is to do nothing in Python 3.3: the API changed, but it
> doesn't really matter. Developers just have to be careful on this particular
> issue (which is not well documented today).
See above. I think there actually is no issue in the first place. Please
do correct me if I'm wrong.
More information about the Python-Dev