The signal:noise ratio due to spam is getting a bit high on this mailing
list. Would the admins be up for turning on default moderation for people
and then selectively turning it off? Or should this group move to
discuss.python.org where spam issues aren't as much of a concern?
Hi,
I wrote a new script which adds Python 3.10 support to your C
extensions without losing Python 3.6 support:
https://github.com/pythoncapi/pythoncapi_compat
For example, it replaces "op->ob_type" with "Py_TYPE(op)" and replaces
"frame->f_back" with "_PyFrame_GetBackBorrow(frame)".
It relies on the pythoncapi_compat.h header file that I wrote to
implement Python 3.9 and Python 3.10 on old Python versions. Examples:
Py_NewRef() and PyThreadState_GetFrame().
The _PyFrame_GetBackBorrow() function doesn't exist in the Python C
API, it's only provided by pythoncapi_compat.h to ease the migration
of C extensions. I advise you to replace _PyFrame_GetBackBorrow()
(borrowed reference) with PyFrame_GetBack() (strong reference). The
PyFrame_GetBack() function was added to Python 3.9 and
pythoncapi_compat.h provides it on older Python versions.
This project is related to my PEP 620 "Hide implementation details
from the C API" which tries to make the C API more abstract to later
allow to implement new optimization in CPython and to make other
Python implementations like PyPy faster when running C extensions.
This project only targets extension modules written in C by using
directly the "Python.h" API. I advise you to use Cython or HPy to no
longer be bothered with incompatible C API changes at every Python
release ;-)
* https://cython.org/
* https://hpy.readthedocs.io/
I hope that my script will facilitate migration of C extensions to HPy.
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
There's more background in the Discourse thread [1], but the key C API
design topic is that PyEval_GetLocals() and PyEval_GetGlobals()
currently behave differently when there's no Python frame active in
the current thread:
* PyEval_GetGlobals(): returns NULL without setting an exception
* PyEval_GetLocals(): returns NULL *and* sets an exception
PyEval_GetLocals() has been doing the latter since it gained the
ability to report memory allocation errors when dealing with optimised
frames back in Python 3.4.
The "no active Python frame" case isn't really an error (as it's a
valid state in applications that embed CPython), so I'm wondering if
PyEval_GetLocals() should partially go back to its pre-3.4 behaviour,
and not set an exception in the "no active Python frame" case.
Cheers,
Nick.
[1] https://discuss.python.org/t/subtle-c-api-discrepancy-pyeval-getlocals-vs-p…
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
EXPY is an express way to extend Python!
EXPY provides a way to extend python in an elegant way. For more information and a tutorial, see: http://expy.sourceforge.net/
What's new:
1. Correct treatment of __init__ method.
2. Give warnings of missing Py_INCREF on
appropriate special type methods.
3. Documentation update.
Cheers,
Yingjie