Le mer. 17 juin 2020 à 12:38, Petr Viktorin
Py_TYPE(), Py_REFCNT() and Py_SIZE() can no longer be used as l-value. These changes also broke numpy. I helped to fix Cython and numpy (and they are already fixed).
Those are not all the projects that were broken by the change -- they're just the most popular ones. Right?
I don't know. So far, I'm only aware of 4 broken projects: Cython, numpy and immutables, pycurl. Some references: * These changes are part of https://bugs.python.org/issue39573 * Cython change: https://github.com/cython/cython/commit/d8e93b332fe7d15459433ea74cd29178c031... * numpy change: https://github.com/numpy/numpy/commit/a96b18e3d4d11be31a321999cda4b795ea9ecc... I'm not sure how Cython works, but affected functions are: * generate_usr_dealloc_call() (something related to "__dealloc__") * __Pyx_PyLong_AbsNeg() * __Pyx_PyList_Append() * __Pyx_PyList_Pop() * __Pyx__PyList_PopIndex() * __Pyx_ListComp_Append()
You can expect further incompatible changes in the C API. For example, I would like to make the PyThreadState structure opaque, whereas Cython currently accesses directly to PyThreadState members.
There is an ongoing discussion about always requiring to run Cython when installing a C extension which uses Cython.
Do you have a link to that discussion?
Hum, I forgot where the discussion happened. Maybe it wasn't a proper "discussion", but just a few tweets: https://twitter.com/tacaswell/status/1266472526806474752 Thomas A Caswell wrote: "also, if you use cython please make it a build-time dependency and please don't put the generated c code in the sdists. cython can only handle the changes in the CPyhon c-api if you let it!"
If PEP 387 (Backwards Compatibility Policy) is accepted, all the incompatible changes changes will require a two-year deprecation period. Right?
For Py_TYPE() which cannot be used as an l-value, I don't see how to emit a deprecation warning. I don't think that anyone would pay attention if you only add a small deprecation note in the C API documentation. For structures made opaque like PyInterepreterState (done in Python 3.8) or PyThreadState (my next target!), again, I don't see how to mark the usage of a structure as "deprecated". My assumption is that only a minority of C extensions will be affected. If this assumption is wrong, we can revert or postpone the incompatible change. So far, it doesn't seem to be a giant disaster :-) Only a few C extensions had to be modified, and only a few lines. For example, the l-value change only required to modify exactly 5 lines in the whole numpy project! -- By the way, I already made C API changes in Python 3.8, especially macros converted to static inline functions: * https://docs.python.org/dev/whatsnew/3.8.html#build-and-c-api-changes * https://vstinner.github.io/split-include-directory-python38.html As far as I recall, these changes didn't cause any issue. Victor -- Night gathers, and now my watch begins. It shall not end until my death.