INADA Naoki schrieb am 07.09.2018 um 18:28:
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.
Which is ok, right? It's obvious from their name that they are not public and thus subject to change at any time (well, probably just with every minor release, though, which should also be an acceptable restriction for CPython).
- 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.
And I would *love* to get access to that. Currently, it's a very hidden implementation detail that's impossible to exploit by extension modules. It's really annoying to have this optimisation (and, actually, the whole dict implementation) right in the code on the other side, but not being able to make direct use of it in Cython, e.g. for faster dict creation or iteration.
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.
What we do in Cython when exploiting some CPython internal feature is to a) implement the code that uses it twice to have a safe (and usually slower) fallback for PyPy and friends, and b) hide it behind a feature macro like "CYTHON_USE_UNICODE_INTERNALS" that users can simply set to "0" in their setup.py (or even CFLAGS) if it ever gets in the way for them.
Stefan