[Python-Dev] Experiment an opt-in new C API for Python? (leave current API unchanged)

[Paul Moore]

On Wed, 14 Nov 2018 at 14:39, Paul Moore <p.f.moore at gmail.com> wrote:

> If it is the case that there's no need for any 3rd party code to
> change in order to continue working with 3.8+, then I apologise for
> the interruption.

This is where being able to edit posts, a la Discourse would be useful :-)

It occurs to me that we may be talking at cross purposes. I noticed
https://pythoncapi.readthedocs.io/backward_compatibility.html#forward-compatibility-with-python-3-8-and-newer
which seems to be saying that 3rd party code *will* need to change for
3.8. You mention removed functions there, so I guess "stop using the
removed functions and you'll work with 3.8+ and <=3.7" is the
compatible approach - but it doesn't offer a way for projects that
*need* the functionality that's been removed to move forward. That's
the type of hard break that I was trying to ask about, and which I
thought you said would not happen when you stated "I don't want to
force anyone to move to a new experimental API", and "No, the current
C API will remain available. No one is forced to do anything. That's
not part of my plan".

So to try to be clear, your proposal is that in 3.8:

1. The existing C API will remain
2. A new C API will be *added* that 3rd party projects can use should
they wish to.

And in 3.9 onwards, both C APIs will remain, maybe with gradual and
incremental changes that move users of the existing C API closer and
closer to the new one (via deprecations, replacement APIs etc as per
our normal compatibility rules). Or is the intention that at *some*
point there will be a compatibility break and the existing API will
simply be removed in favour of the "new" API? Fundamentally, that's
what I'm trying to get a clear picture of.

The above is clear, but I don't see what incentive there is in that
scenario for anyone to actually migrate to the new API...
Paul