Fri Mar 26 11:03:32 CET 2010

M.-A. Lemburg, 26.03.2010 10:20:
> Larry Hastings wrote:
>> 3. Because CObject is unsafe, I want to deprecate it in 2.7, and if we
>> ever made a 2.8 I want to remove it completely.
>
> Please remember that PyCObjects are not only used internally
> in CPython, but also in other 3rd party modules to expose C APIs
> and those will generally have to support more than just the latest
> Python release.

The removal of PyCObject from Py3.2 pretty much caught the Cython project 
by surprise, as they had been The One Obvious Way for public C-APIs for 
ages. We quickly switched to PyCapsule back then, but only for newer 3.x 
versions. This is easy to do when your code relies on Cython (or its 
generated header files) for importing and exporting this C-API, as a 
rebuild will just do all the work for you. However, if you have to do this 
manually, you will basically have to write all the code yourself that 
Cython now generates.

If this can be done using preprocessor macros, fine. But the underlying ABI 
should not be changed in Py2.x. The normal 2.x approach would be to add the 
new API *in addition* to the old one, potentially by providing macros that 
map the new functionality to the old one, but not the other way round. That 
would allow code to be written that works in both Py2.7 and Py3.2+, without 
breaking backwards compatibility with existing Py2.x libraries.

And, no, recompilation is not always an option and certainly shouldn't be 
required for the soon to be discontinued 2.x line. The *only* reason for 
the very existence of 2.7 is to not break backwards compatibility.

> If you deprecate those C APIs, the process will at least have to cover
> one more release, i.e. run through the whole deprecation process:
>
> 1. pending deprecation (2.7)
> 2. deprecation (2.8)
> 3. removal (2.9)

If you replace 2.8 by 3.1 and 2.9 by 3.2, that's more or less what has 
happened already. No need to put any more thoughts into Py2.x for that purpose.

Stefan