On Fri, Jun 5, 2020 at 10:55 AM Victor Stinner firstname.lastname@example.org wrote:
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.
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 proposal is that Python.h gets the same treatment as Python 2.7 did, frozen with bug fixes only going forward. After a few years, abandoned.
In this case, if I'd thought of this earlier and it had been adopted, the new PyFrame_GetCode function would be added to python_api.h, not Python.h.
python_api.h itself gets added to previous releases of Python, as far back as possible. For those releases it relies on a backwards compatible library implementing the new API on top of the old.
Developers who don't want to to change over to the new API continue to #include Python.h. There's no pythoncapi_compat.h, as Python.h itself now serves that purpose.
Developers who #include python_api.h are signing up for the new API, and accepting that the transition may be bumpy and with breaking changes for the near future.
cheers, Hugh Fisher