As someone who maintains a debugger that uses private api’s, I’d like to see some commitment to seeing them not change in micro releases such as 3.11.1 -> 3.11.2. Micro releases should be compatible with other micro releases of the same major.minor release such as 3.11 so that an extension compiled against 3.11.1 will work with 3.11.2.
Compatibility was broken (at least) once in a 2.x series (maybe 2.4?) and we started getting reports of people using 2.x.0 were having problems. Fortunately, in that case compiling against 2.x.0 produced an extension that worked against all micro releases. Note that I’m not asking for private api’s not change in major.micro releases such as 3.10 -> 3.11. I know that there can be very good reasons to change private api's because that I probably will have work to do in order to support a new major.micro release. I also don’t think that exposing everything that every extension needs with a non-private api is a good idea because then the internals will be more difficult to change — you’d be signing up to support that api for all future major.micro versions until there’s a compatibility break. John > On Mar 30, 2022, at 11:01 AM, Victor Stinner <vstin...@python.org> wrote: > > The internal C API can be used on purpose. But there is no backward > compatibility warranty and it can change anytime. In practice, usually > it only changes in 3.x.0 releases. For example, these private C API > changed in Python 3.9 and Python 3.11 (see my first email in the other > PEP 523 thread). > > To use the internal C API, you have to declare the Py_BUILD_CORE macro > and include an internal C API header file. For > _PyInterpreterState_SetEvalFrameFunc(), it should be: > > #ifndef Py_BUILD_CORE_MODULE > # define Py_BUILD_CORE_MODULE > #endif > #include <Python.h> > #include <internal/pycore_interp.h> // _PyInterpreterState_SetEvalFrameFunc() > #include <internal/pycore_ceval.h> // _PyEval_EvalFrameDefault > > Victor > > On Tue, Mar 29, 2022 at 12:26 AM Jason Ansel via Python-Dev > <python-dev@python.org> wrote: >> >> The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this >> proposal may break the next major release of PyTorch. >> >> The related project is TorchDynamo, which can be found here: >> https://github.com/facebookresearch/torchdynamo >> >> We will likely move this into the core of PyTorch closer to release. >> >> If the changed happens, would PyTorch still be able to use the eval frame >> API? Or would it prevent from being used entirely? >> _______________________________________________ >> 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/RVQ7LDIJ2OYAN4QMIPTI3A3PODGBLNN7/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > 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/OQTAF6CQRKHQPYUY5HWVOTUAEXKHI5WE/ > Code of Conduct: http://python.org/psf/codeofconduct/ _______________________________________________ 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/TK27HEVDUWQQZQ4XIKTQLDHWK52ZLHWN/ Code of Conduct: http://python.org/psf/codeofconduct/
