On 11/20/2018 2:17 PM, Victor Stinner wrote:
Le mar. 20 nov. 2018 à 23:08, Stefan Krah <ste...@bytereef.org> 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
_______________________________________________
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
