On 11/20/2018 2:17 PM, Victor Stinner wrote:
Le mar. 20 nov. 2018 à 23:08, Stefan Krah
a écrit : Intuitively, it should probably not be part of a limited API, but I never quite understood the purpose of this API, because I regularly need any function that I can get my hands on. (...) Reading typed strings directly into an array with minimal overhead. IMHO performance and hiding implementation details are exclusive. You should either use the C API with impl. details for best performances, or use a "limited" C API for best compatibility.
The "limited" C API concept would seem to be quite sufficient for extensions that want to extend Python functionality to include new system calls, etc. (pywin32, pyMIDI, pySide, etc.) whereas the numpy and decimal might want best performance.
Since I would like to not touch the C API with impl. details, you can imagine to have two compilation modes: one for best performances on CPython, one for best compatibility (ex: compatible with PyPy). I'm not sure how the "compilation mode" will be selected.
The nicest interface from a compilation point of view would be to have two #include files: One to import the limited API, and one to import the performance API. Importing both should be allowed and should work. If you import the performance API, you have to learn more, and be more careful. Of course, there might be appropriate subsets of each API, having multiple include files, to avoid including everything, but that is a refinement.
Victor _______________________________________________ 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/v%2Bpython%40g.nevcal.com