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: HPy (#2169)

This commit is contained in:
Victor Stinner 2021-12-01 17:39:49 +01:00 committed by GitHub
parent 23c90120e3
commit 6caef0d18c
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 13 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
pep-0674.rst
View File

@ -80,24 +80,21 @@ HPy project
The `HPy project <https://hpyproject.org/>`_ is a brand new C API for
Python using only handles and function calls: handles are opaque,
structure members cannot be accessed directly,and pointers cannot be
structure members cannot be accessed directly, and pointers cannot be
dereferenced.
Disallowing the usage of macros as l-value helps the migration of
existing C extensions to HPy by reducing differences between the C API
and the HPy API.
Searching and replacing ``Py_SET_SIZE()`` is easier and safer than
searching and replacing some strange macro uses of ``Py_SIZE()``.
``Py_SIZE()`` can be semi-mechanically replaced by ``HPy_Length()``,
whereas seeing ``Py_SET_SIZE()`` would immediately make clear that the
code needs bigger changes in order to be ported to HPy (for example by
using ``HPyTupleBuilder`` or ``HPyListBuilder``).
PyPy cpyext module
------------------
The fewer internal details exposed via macros, the easier it will be for
HPy to provide direct equivalents. Any macro that references
"non-public" interfaces effectively exposes those interfaces publicly.
In PyPy, when a Python object is accessed by the Python C API, the PyPy
``cpyext`` module has to convert PyPy object to a CPython object. While
PyPy objects are designed to be efficient with the PyPy JIT compiler,
CPython objects are less efficient and increase the memory usage.
This PEP alone is not enough to get rid of the CPython objects in the
PyPy ``cpyext`` module, but it is a step towards this long term goal.
PyPy already supports HPy which is a better solution in the long term.
These statements are endorsed by Antonio Cuni (HPy developer).
Specification
@ -292,8 +289,8 @@ API documentation. The majority of developers are only using CPython and
so are not aware of compatibility issues with other Python
implementations.
Moreover, continuing to allow using macros as l-value does not solve
issues of the nogil, PyPy and HPy projects.
Moreover, continuing to allow using macros as l-value does not help the
HPy project.
Macros already modified