I added FASTCALL to Python 3.6. I chose to make it private on purpose, we didn't have enough feedback to know if the whole idea of FASTCALL was a good idea or not. It took one or two years to cleanup the code and the exact API. METH_FASTCALL changed deeply in Python 3.7: it doesn't include keyword arguments anymore.
About Cython: the fact that it was private didn't prevent Cython to use METH_FASTCALL since Python 3.6, and so Cython was broken in Python 3.7. Well, it's a deliberate choice of Cython, and I'm fine with that. I'm also interested to help to keep Cython up to date :-)
Victor Le ven. 7 sept. 2018 à 18:29, INADA Naoki firstname.lastname@example.org a écrit :
On Fri, Sep 7, 2018 at 10:25 PM Jeroen Demeyer J.Demeyer@ugent.be wrote:
On 2018-09-07 14:47, Victor Stinner wrote:
Inside CPython, the core and builtin modules, micro-optimizations must be used: abuse borrowed references, macros, access directly to all fields of C structure, etc.
But here I'm talking about the public C API used by third party extensions.
Making a difference between "inside CPython" and "third party extensions" is a bad idea. Making such a difference would be problematic:
I can't agree.
- Complexity: we should not have two different C APIs. There should be
just one, usable internally and externally.
Most of these private APIs, we don't have "two different APIs". We have just one private API.
Internal APIs (functions starts with _Py / macros starts with _PY) are just private functions in most case. It is used only for calling over compile unit. If we start all internal API public, we can't keep backward compatibility.
For example, gc module calls "_PyTuple_MaybeUntrack" https://github.com/python/cpython/blob/886483e2b9bbabf60ab769683269b873381dd...
It is highly depending on implementation detail of GC and tuple. Making it public is not make sense.
- Performance: if an optimization is important for CPython, then it's
also important for third-party extensions. We don't want third-party code to be inherently slower than CPython itself. (this reminds me of PEP 580, regarding several internal optimizations which aren't available to third-party classes)
Which extension type is important as same as builtin str, tuple, int?
For example, dict implementation have special casing for str key. It's because (1) dict is heavily used for namespace, and (2) key of namespace is very likely str.
In some cases, special casing for builtin types is necessary.
In case of FASTCALL, it is private because it is under development and no one thought it's stable enough to keep backward compatibility in some future versions.
I agree that we should make FASTCALL accessible from third parties in 3.8.
But I think we should have "evolution era" for some important new APIs. And calling it from builtin modules is important for learning the API before making it public, like FASTCALL is evolved between 3.6 and 3.7.
-- INADA Naoki email@example.com _______________________________________________ capi-sig mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com