On Sun, 8 Jul 2018 00:14:13 +1000 Nick Coghlan <ncogh...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com