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."