<div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 16 Nov 2018 at 10:11, Paul Moore <<a href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 16 Nov 2018 at 17:49, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
> 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.<br>
<br>
If a stripped down API like this is intended as "use this and you get<br>
compatibility across multiple Python interpreters and multiple Python<br>
versions" (essentially a much stronger and more effective version of<br>
the stable ABI) then I'm solidly in favour (and such an API has clear<br>
trade-offs that allow people to judge whether it's the right choice<br>
for them).<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Having this alongside the existing API, which would still be supported<br>
for projects that need low-level access or backward compatibility (or<br>
simply don't have the resources to change), but which will remain<br>
CPython-specific, seems like a perfectly fine idea.<br></blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div></div></div></div>