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

[Brett Cannon]

On Fri, 16 Nov 2018 at 10:11, Paul Moore <p.f.moore at gmail.com> wrote:

> On Fri, 16 Nov 2018 at 17:49, Brett Cannon <brett at python.org> wrote:
> > And Just to be clear, I totally support coming up with a totally
> stripped-down C API as I have outlined above as that shouldn't be
> controversial for any VM that wants to have a C-level API.
>
> If a stripped down API like this is intended as "use this and you get
> compatibility across multiple Python interpreters and multiple Python
> versions" (essentially a much stronger and more effective version of
> the stable ABI) then I'm solidly in favour (and such an API has clear
> trade-offs that allow people to judge whether it's the right choice
> for them).
>

Yes, that's what I'm getting at. Basically we have to approach this from
the "start with nothing and build up until we have _just_ enough and thus
we know **everyone** now and into the future can support it", or we
approach with "take what we have now and start peeling back until we
_think_ it's good enough". Personally, I think the former is more
future-proof.


>
> Having this alongside the existing API, which would still be supported
> for projects that need low-level access or backward compatibility (or
> simply don't have the resources to change), but which will remain
> CPython-specific, seems like a perfectly fine idea.
>

And it can be done as wrappers around the current C API and as an external
project to start. As Nathaniel pointed out in another thread, this is
somewhat like what Py_LIMITED_API was meant to be, but I think we all admit
we slightly messed up by making it opt-out instead of opt-in and so we
didn't explicitly control that API as well as we probably should have (I
know I have probably screwed up by accidentally including import functions
by forgetting it was opt-out).

I also don't think it was necessarily designed from a minimalist
perspective to begin with as it defines things in terms of what's _not_ in
Py_LIMITED_API instead of explicitly listing what _is_. So it may (or may
not) lead to a different set of APIs in the end when you have to explicitly
list every API to include.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20181118/8bcee959/attachment.html>