Stefan Krah added the comment: R. David Murray <rep...@bugs.python.org> wrote: > My understanding was that code that calls the public APIs should continue to > work. Is this a new requirement in 3.3, or is it that it has always been a > requirement but code could get away without the ready before?
It's a new requirement. > Either way we need to add an note to the Porting section of What's New. Good point. The main hint I find is here: http://docs.python.org/py3k/whatsnew/3.3.html#deprecated-functions-and-types-of-the-c-api But you have to click through to: http://docs.python.org/py3k/c-api/unicode.html#PyUnicode_FromUnicode PEP 393 on the other hand has this paragraph: "Extension modules using the legacy API may inadvertently call PyUnicode_READY, by calling some API that requires that the object is ready, and then continue accessing the (now invalid) Py_UNICODE pointer. Such code will break with this PEP. The code was already flawed in 3.2, as there is was no explicit guarantee that the PyUnicode_AS_UNICODE result would stay valid after an API call (due to the possibility of string resizing). Modules that face this issue need to re-fetch the Py_UNICODE pointer after API calls; doing so will continue to work correctly in earlier Python versions." ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16145> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
