iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 674: GraalPython C API emulation rationale (#2171)

This commit is contained in:
Tim Felgentreff 2021-12-01 18:33:11 +01:00 committed by GitHub
parent 6caef0d18c
commit 7d8c2a104a
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 19 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
pep-0674.rst
View File

@ -96,6 +96,23 @@ HPy to provide direct equivalents. Any macro that references
These statements are endorsed by Antonio Cuni (HPy developer).
GraalVM Python
--------------
In GraalVM, when a Python object is accessed by the Python C API, the C API
emulation layer has to wrap the GraalVM objects into wrappers that expose
the internal structure of the CPython structures (PyObject, PyLongObject,
PyTypeObject, etc). This is because when the C code accesses it directly or via
macros, all GraalVM can intercept is a read at the struct offset, which has
to be mapped back to the representation in GraalVM. The smaller the
"effective" number of exposed struct members (by replacing macros with
functions), the simpler GraalVM wrappers can be.
This PEP alone is not enough to get rid of the wrappers in GraalVM, but it
is a step towards this long term goal. GraalVM already supports HPy which is a better
solution in the long term.
These statements are endorsed by Tim Felgentreff (GraalVM Python developer).
Specification
=============
@ -290,7 +307,8 @@ so are not aware of compatibility issues with other Python
implementations.
Moreover, continuing to allow using macros as l-value does not help the
HPy project.
HPy project and leaves the burden of emulating them on GraalVM's Python
implementation.
Macros already modified