From db0a554b4530c370eef0b61c5c6e352361ba3584 Mon Sep 17 00:00:00 2001 From: Tim Felgentreff Date: Wed, 1 Dec 2021 18:21:11 +0100 Subject: [PATCH 1/2] PEP 674: GraalPython C API emulation rationale --- pep-0674.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/pep-0674.rst b/pep-0674.rst index 05ff2ccef7f..10db100a812 100644 --- a/pep-0674.rst +++ b/pep-0674.rst @@ -96,6 +96,21 @@ HPy to provide direct equivalents. Any macro that references These statements are endorsed by Antonio Cuni (HPy developer). +GraalPython +----------- + +In GraalPython, when a Python object is accessed by the Python C API, the C API +emulation layer has to wrap the GraalPython 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 GraalPython can intercept is a read at the struct offset, which has +to be mapped back to the representation in GraalPython. The smaller the +"effective" number of exposed struct members (by replacing macros with +functions), the simpler GraalPython wrappers can be. + +This PEP alone is not enough to get rid of the wrappers in GraalPython, but it +is a step towards this long term goal. PyPy already supports HPy which is a better +solution in the long term. Specification ============= From 6fef4511f462601de24710737d4b29a62d7629e2 Mon Sep 17 00:00:00 2001 From: Tim Felgentreff Date: Wed, 1 Dec 2021 18:26:25 +0100 Subject: [PATCH 2/2] PEP 674: GraalVM Python rewording and touch ups --- pep-0674.rst | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/pep-0674.rst b/pep-0674.rst index 10db100a812..ddec1cc6d68 100644 --- a/pep-0674.rst +++ b/pep-0674.rst @@ -96,22 +96,24 @@ HPy to provide direct equivalents. Any macro that references These statements are endorsed by Antonio Cuni (HPy developer). -GraalPython ------------ +GraalVM Python +-------------- -In GraalPython, when a Python object is accessed by the Python C API, the C API -emulation layer has to wrap the GraalPython objects into wrappers that expose +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 GraalPython can intercept is a read at the struct offset, which has -to be mapped back to the representation in GraalPython. The smaller the +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 GraalPython wrappers can be. +functions), the simpler GraalVM wrappers can be. -This PEP alone is not enough to get rid of the wrappers in GraalPython, but it -is a step towards this long term goal. PyPy already supports HPy which is a better +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 ============= @@ -305,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