capi-sig March 2021

capi-sig@python.org

12 participants
14 discussions

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

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

ANNOUNCE: PyBindGen 0.8
by Gustavo Carneiro 10 Mar '22

10 Mar '22

The other day I released PyBindGen 0.8. Main news is that it features a new experimental header file scanner based on pygccxml (i.e., it's similar to py++ in scope, if not in maturity, but does not use boost.pythonunderneath). == What == PyBindGen is a Python module that is geared to generating C/C++ code that binds a C/C++ library for Python. It does so without extensive use of either C++ templates or C pre-processor macros. It has modular handling of C/C++ types, and can be easily extended with Python plugins. The generated code is almost as clean as what a human programmer would write, and does not depend on any library or header files besides Python itself. == Where == https://launchpad.net/pybindgen/ == NEWS == - Support C++ instance attributes through getter/setter methods - Support functions as methods of C++ classes - Support the PyObject* type - Support unsigned int, C strings (char*) (from Mark Lee) - Add basic support for enum types - New experimental automatic module generator based on C/C++ header file scanner and annotations in comments, using pygccxml - Some bug fixes -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit "The universe is always one step beyond logic." -- Frank Herbert

2 1

C API equivalent to abc.ABCMeta.register?
by Daniel Stutzbach 02 Mar '22

02 Mar '22

I'm the author of an extension module (blist) that provides a type that fits the MutableSequence API. Is there a canonical way for me to register the type as a MutableSequence from the C API? -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>

3 2

Software Development - Application Development - Game Development
by Gary 10 Jan '22

10 Jan '22

You are receiving this email because we wish you to use our cost-effective IT services. We are a China based Custom Software Application Development provider. We offer full cycle custom software programming services, from product idea, software development to support and enhancement. We employ a large pool of software engineers coming from different backgrounds. We are able to balance product development efforts and project duration to your business needs. Core Services: Custom Application Development Custom Software Development iPhone Application Development iPad Application Development Mobile Application Development Android Mobile Application Development Soft Product Development Game Design & Development Game Testing & Quality Assurance Cloud Computing Solutions: CRM Software Application Development ERP Software Application Development Enterprise Portal Solution Sales Force Automation Solution Game Design & Development Knowledge Management Solution Workflow Management Solution SharePoint Development Services Microsoft Online Services Microsoft Azure Services Best regards, Gary ITVIATSA Software Development Contact: ibsoftware(a)yeah.net Pls send address to larryremove123(a)msn.com for remove

2 2

Mail l8st
by casperssidekick 09 Jul '21

09 Jul '21

Sent from my Verizon, Samsung Galaxy smartphone

2 1

New HPy Blog
by Antonio Cuni 29 Mar '21

29 Mar '21

Hello, since it is very relevant to the topic of this mailing list, I'd like to announce the new HPy blog (and its first post): https://hpyproject.org/blog/posts/2021/03/hello-hpy/ Any feedback (both on the blog post and on hpy itself) is appreciated! cheers, Antonio

1 0

Subject: The stable ABI is not going away
by Petr Viktorin 26 Mar '21

26 Mar '21

Hello list! After the e-mails from the previous week, I set up a call with Eric to sync on Limited API/Stable ABI issues. The higher-bandwidth (and more emotion-friendly) medium worked great for us, but unfortunately, everyone else was excluded. Here are some rather unstructued notes from my point of view. They might be good discussion starters :) Please read PEP 652 “Maintaining the Stable ABI” for my thoughts, plans and rationales for the short term. For the long term, there are some more vague plans and ideas: There's not a 1:1 mapping between “Limited API”, “Stable ABI” and “C-API, the Good Parts™”, *but* unless you're deep in this space, it makes sense to conflate them. I aim to make them converge. I intend to focus my CPython time on Limited API/Stable ABI for the next... few years, probably. The work I'm doing (extension isolation & now stable ABI) is similar to the subinterpreters effort in several ways: - They are both incomplete, but useful *today* for some limited cases, and have lots of potential - They need long-term effort, but most of the many steps are useful in their own right. In addition to the use cases in PEP 652, the stable ABI *should* ideally be useful for: - bindings for non-Python software, where shoehorning Python into the buildsystem is not straightforward and building for several Python versions at once is not practical. Also, raw speed tends to not matter. - GUI apps, whose scripting plugins could use any Python the user/scripter has installed. (Think Blender, if it was a smaller project that couldn't afford to bundle Python.) And here's some more concrete stuff. (Remember that these are still vague ideas): Static `PyObject` and `PyObject*` are the main thing in the Limited API that's blocking subinterpreters. We see no other blockers. A possible way to solve this is to make isolated subinterpreters support *opt-in* for extension modules: - Introduce a macro similar to the old PY_SSIZE_T_CLEAN that removes the problematic items from the headers. - This macro will give you access to a flag you can use to tell the runtime the extension is subinterp-safe. - Python will support both the current, GIL-sharing subinterpreters, and isolated subinterpreters. (All signs say implementing this will be easy, relative to making subinterpreters always isolated and breaking existing code.) - The macro will affect both the full API and the limited subset.

4 5

Get Rid of the Stable ABI?
by Eric Snow 23 Mar '21

23 Mar '21

PEP 384 [1] introduced the limited API (AKA Py_LIMITED_API) and stable ABI. The main objective: "Extension modules and applications embedding Python can work with different feature releases as long as they restrict themselves to this stable ABI." This goal is completely reasonable, particularly in 2009. Furthermore, even though there are things we would have done differently, in hindsight, the limited API mostly reaches that goal. However, is it relevant in the current ecosystem? The burden on extension maintainers to build for each Python release is much lower now. At the same time, the maintenance burden of the current limited API (especially ABI compatibility) is relatively high, especially for our group of volunteers. It also makes some improvements harder. [2] So the question is: Is the stable ABI still worth it? If not, what would be the impact of abandoning it? Note that the limited API is fine on its own, though I'll argue that we should re-focus it (PEP 652?) and use a new name (to differentiate from the API tied to the stable ABI). [3] -eric [1] https://www.python.org/dev/peps/pep-0384/ [2] https://bugs.python.org/issue43503 [3] https://mail.python.org/archives/list/capi-sig@python.org/thread/DX2HNPMJLI…

2 2

Move the limited API to distinct headers.
by Eric Snow 22 Mar '21

22 Mar '21

(Sorry for all the posts related to the limited API. It's been a pain point for me lately.) Would it be feasible to have distinct header files that contain only the limited API (perhaps in Include/limited)? The files could be auto-generated to avoid duplicated code (like other files in the repo), though the nature of the limited API suggests the only future changes would be opt-in ones, which should be manual anyway. If there is no auto-generation then there should be a test to ensure the limited API matches the corresponding public API definitions exactly. Either way, Include/Python.h would have to be updated to switch to Include/limited if Py_LIMITED_API is defined. Also, FWIW, Include/limited would effectively fill the role of the manifest described in PEP 652. [1] With Include/limited, would we still need Include/cpython? I suppose we could keep only public API in Include/*.h and keep "private-but-not-internal" API in Include/cpython (or rename it to Include/private or Include/unstable). Finally, is the separation of headers by access "rings" worth it? On the one hand it makes the divisions explicit and obvious and helps avoid API leaking out accidentally. We'd had success in that regard with Include/internal and Include/cpython. On the other hand, the divisions mean related API is often spread out across multiple files (albeit with matching names), where otherwise those would all be in one file. Anway, this is something that came to mind as I was writing up my other posts to this list. -eric [1] https://www.python.org/dev/peps/pep-0652/#stable-abi-manifest

5 7

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

capi-sig March 2021