Home Original page

[Python-Dev] PEP 575, 576, 579 and 580

Antoine Pitrou solipsis at pitrou.net
Sat Jul 7 10:50:58 EDT 2018 
On Sun, 8 Jul 2018 00:14:13 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> > So, let us gather the requirements for a new calling API.  
> 
> > Here are my starting suggestions:
> >
> > 1. The new API should be fully backwards compatible and shouldn't break the
> > ABI
> > 2. The new API should be used internally so that 3rd party extensions are
> > not second class citizens in term of call performance.
> > 3. The new API should not prevent 3rd party extensions having full
> > introspection capabilities, supporting keyword arguments or another feature
> > supported by Python functions.
> > 4. The implementation should not exceed D lines of code delta and T lines of
> > code in total size. I would suggest +200 and 1000 for D and T respectively
> > (or is that too restrictive?).
> > 5. It should speed up CPython for the standard benchmark suite.
> > 6. It should be understandable.  
> 
> I like points 1, 2, 3, and 6, but I think point 4 should be a design
> trade-off rather than a requirement, since minimising the delta in
> CPython becomes an anti-goal if the outcome of doing so is to make the
> change harder to adopt for third party projects (at the same time, a
> delta that's too large is unlikely to be accepted, reviewed and
> merged, which is what makes it a trade-off).
> 
> I don't think point 5 is a goal here either, as the problem isn't that
> these calling optimisations don't exist, it's that they don't
> currently have a public API that third party projects can access (the
> most recent METH_FASTCALL thread covers that pretty well).

Agreed.  The goal is not to speed up CPython but to bring third-party
extensions up to speed (both literally and figuratively).

Regards

Antoine.
More information about the Python-Dev mailing list