I don't think such a guarantee (to not vary internal APIs from 3.x.y to 3.x.(y+1)) has ever before been made in writing, although in practice we've been doing this (more so now than we were in the 2.x timeframe).

I think we should not lightly vary internal APIs between bugfix releases, but at the same time I am not sure I want to absolutely guarantee that no internal API ever changes in a bugfix release (because that might prevent fixing certain bugs).

So I think we need to officially embrace a category of "unstable public APIs" and set a policy specifically for those, before we can make progress.

I'd like the SC to take some initiative here.

On Wed, Mar 30, 2022 at 9:34 AM Jason Ansel via Python-Dev <python-dev@python.org> wrote:

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.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/U7M65SSDZMM7LNAKEDZZ4KKQIFTCOQ2M/
Code of Conduct: http://python.org/psf/codeofconduct/