
I'm not sure that we are talking about the same thing. Let's take an example. Python 3.9 added the PyFrame_GetCode() function. In the future, PyFrameObject may become an opaque structure, and so all C extensions accessing PyFrameObject would have to replace "f->f_code" with PyFrame_GetCode() (and fix reference counting, since PyFrame_GetCode() returns a strong reference.
https://github.com/pythoncapi/pythoncapi_compat/blob/master/pythoncapi_compa...
Python.h of Python 3.9 do add the new PyFrame_GetCode() function.
My question is how to provide PyFrame_GetCode() on Python 3.8 and older, so a C extension modified to use PyFrame_GetCode() can now be compiled on Python 3.9 (and newer) *and* Python 3.8 (and older). Python version N cannot depend on Python version N+1.
My proposition is to provide a pythoncapi_compat.h header file separately. PyFrame_GetCode() is implemented as static inline function:
#if PY_VERSION_HEX < 0x030900B1 static inline PyCodeObject* PyFrame_GetCode(PyFrameObject *frame) { assert(frame != NULL); PyCodeObject *code = frame->f_code; assert(code != NULL); Py_INCREF(code); return code; } #endif
https://github.com/pythoncapi/pythoncapi_compat/blob/b5bce9c469b56a3dc9cbc41...
Or you may look at PyObject_GC_IsTracked() function which is simply a new feature, but it's not related to any backward incompatible change. It's also possible to provide PyObject_GC_IsTracked() on Python 3.8 and older by the same way.
Victor
Le ven. 5 juin 2020 à 02:19, Hugh Fisher <hugo.fisher@gmail.com> a écrit :
Having read my own email about goals, I realise my previous suggestion was all wrong.
The backwards compatibility header file should be Python.h! The new AP is in python_api.h or whatever. Existing code doesn't change and still works fine, code updated to the new API is clearly marked as such.
Python.h goes through two or three stages over the next few releases.
- Compiling with Python.h generates a single warning, the initial reminder that you should update your code sometime. That might be the only change.
- Python.h is implemented largely or entirely using the new API. Warning(s) are louder and more visible.
- Python.h becomes one line #error "UPDATE YOUR CODE"
And a good first step for the new python_api.h will be the backwards compatibility library, so developers can test that the new thing really does provide the capabilities of the old.
--
cheers, Hugh Fisher
-- Night gathers, and now my watch begins. It shall not end until my death.