Author skrah
Recipients Arfrever, pitrou, r.david.murray, rogerbinns, serhiy.storchaka, skrah
Date 2012-10-05.20:59:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
R. David Murray <> 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:

But you have to click through to:

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."
Date User Action Args
2012-10-05 20:59:21skrahsetrecipients: + skrah, pitrou, rogerbinns, Arfrever, r.david.murray, serhiy.storchaka
2012-10-05 20:59:21skrahlinkissue16145 messages
2012-10-05 20:59:20skrahcreate