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 <vstin...@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.do...@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-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/U7M65SSDZMM7LNAKEDZZ4KKQIFTCOQ2M/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/J3G5RO4FUO3Y3WJ2AJAUMJNS2BXYZ7J7/ Code of Conduct: http://python.org/psf/codeofconduct/
