Got it, thanks for the clarifications! Tracking 3.x Python versions is fine. We already need to do that to support things like new bytecodes, and PyTorch supports an explicit list of 3.x Python versions with separate builds for each. Tracking 3.x.y Python versions would be much more painful, and make us need to rethink our approach. So what Steve Downer described as "remain compatible within a single 3.x release", seems like exactly what we want. I support that level of compatibility guarantee. Could we keep that guarantee with this change? Thanks, Jason ________________________________________ From: Victor Stinner <vstinner@python.org> Sent: Wednesday, March 30, 2022 7:56 AM To: Steve Dower Cc: Jason Ansel; python-dev@python.org Subject: Re: [Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API On Wed, Mar 30, 2022 at 2:26 AM Steve Dower <steve.dower@python.org> wrote:
Right now, the API is allowed/expected to change between 3.x releases (which normally we don't allow without a deprecation period) but it still has to remain compatible within a single 3.x release. Making it fully internal *without adding a stability guarantee* means it could change more frequently, which you wouldn't be able to handle as an installable package.
It's *unlikely* that it'll change that often, because there are still other public interfaces that cannot. But, the plan behind this is to make more stuff internal so that it can be modified more freely, so we may see that rate of change increase.
Well, my plan is not break these internal C API just for fun. It's only to better "advertise" the separation between the "stable" public C API (backward compatibility warranty) and the "unstable" private/internal C API (can change any time, changes are not documented). Victor -- Night gathers, and now my watch begins. It shall not end until my death.