Victor Stinner wrote:
> Hi Nick,
> Le dim. 29 sept. 2019 à 08:47, Nick Coghlan firstname.lastname@example.org a écrit :
> > I don't quite understand the purpose of this change,
> > as there's no
> > stable ABI for applications embedding CPython.
> > Well, I would like to prepare Python to provide a stable ABI for
> embedded Python. While it's not a design goal yet
> (Include/cpython/initconfig.h is currently excluded from
> Py_LIMITED_API), this change is a step towards that.
So then isn't this a very last-minute, premature optimization if it isn't a design goal yet? If that's the case then I would vote not to make the change and wait until there's been feedback on 3.8 and then look at stabilizing the embedding API such that it can be considered stable.
I just want to chime in here and confirm, as a Professional CPython Embedder(tm) that embedders cannot currently rely on a stable ABI, or the limited API, and often not even the public API. It's not just about exposed symbols and struct sizes, it's often also about the semantics of internals (e.g. how importlib handles custom module finders and loaders) that subtly changes. For anything but the simplest PyRun_SimpleString-based embedding this is more the case when embedding than extending, and even than a regular (complex) Python program. (I already showed Victor and a few others some of the hoops we have to jump through at Google to embed CPython correctly, and only half of those things are necessary just because of Google's environment.)
On the other hand, py2app uses a single executable that loads a python shared library, initialises the interpreter and runs a script with minimal changes over the years. I’ve basically only needed to recompile to support new macOS architectures and to add support for Python 3.
That said, py2app’s stub executable is basically just “simple PyRun_SimpleString-based embedding” with ugly code to make it possible to use dlopen to load its dependencies.