Mailman 3 April 2022 - capi-sig

Require moderation or move to discuss.python.org?
by Brett Cannon 11 May '22

11 May '22

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?

7 11

New script: add Python 3.10 support to your C extensions without losing Python 3.6 support
by Victor Stinner 07 May '22

07 May '22

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.

2 2

How can we make Python's C-API more friendly for non-C languages?
by Petr Viktorin 06 May '22

06 May '22

In my [C API strategy draft], there wasn't much opposition to the goal of being “easily usable from non-C languages”. But it's clear that as CPython devs we don't have that much relevant experience with those languages. I would like to ask developers of Python bindings, FFIs and alternate C-API implementations for thoughts, suggestions, and pain points to help guide the future of the C-API. I'll collect thoughts in this Google document, though I'm happy to discuss anywhere else: https://docs.google.com/document/d/1fDfF7JanOEyQ9awhKE87-Ajp3H4k7qXL3cmyzPM… I've already asked: - PyPy/cpyext: https://mail.python.org/archives/list/pypy-dev@python.org/thread/44IO4GHWBE… - PyO3 (Rust): https://github.com/PyO3/pyo3/discussions/2346 - nanobind (C++): https://github.com/wjakob/nanobind/discussions/31 If you know more, please let them (or me) know! [C API strategy draft]: https://docs.google.com/document/d/1lrvx-ujHOCuiuqH71L1-nBQFHreI8jsXC966AFu…

5 4

Subtle C API discrepancy: PyEval_GetLocals() vs PyEval_GetGlobals() with no active Python frame
by Nick Coghlan 29 Apr '22

29 Apr '22

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

2 1

ANN: expy 0.6.5 released!
by Yingjie Lan 16 Apr '22

16 Apr '22

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

3 3

capi-sig April 2022