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 <20121005205921.GA18037@sleipnir.bytereef.org>
In-reply-to <1349469957.27.0.3601455737.issue16145@psf.upfronthosting.co.za>
Content
R. David Murray <report@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."
History
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