[Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Include/cStringIO.h Include/cobject.h Include/datetime.h Include/py_curses.h Include/pycapsule.h Include/pyexpat.h Include/ucnhash.h Lib/test/test_sys.py Makefile.pre.in Misc/NEWS Modules/_ctypes/callproc.c Modules/_ctypes/cfield.c Modules/_ctypes/ctypes.h Modules/_cursesmodule.c Modules/_elementtree.c Modules/_testcapimodule.c Modules/cStringIO.c Modules/cjkcodecs/cjkcodecs.h Modules/cjkcodecs/multibytecodec.c Modules/cjkcodecs/multibytecodec.h Modules/datetimemodule.c Modules/pyexpat.c Modules/socketmodule.c Modules/socketmodule.h Modules/unicodedata.c Objects/capsule.c Objects/object.c Objects/unicodeobject.c PC/VS7.1/pythoncore.vcproj PC/VS8.0/pythoncore.vcproj PC/os2emx/python27.def
stefan_ml at behnel.de
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.
More information about the Python-Dev