Le mer. 17 juin 2020 à 12:38, Petr Viktorin <encu...@gmail.com> a écrit : > > 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/d8e93b332fe7d15459433ea74cd29178c03186bd * numpy change: https://github.com/numpy/numpy/commit/a96b18e3d4d11be31a321999cda4b795ea9eccaa 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. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SCXC5CYU66BOT2VXW67BXTEQZBZ6VWSY/ Code of Conduct: http://python.org/psf/codeofconduct/
