On 10May2019 1832, Victor Stinner wrote:
Hi,
First of all, I just found an old issue that we will solved by my PEP 587 :-)
Add Py_SetFatalErrorAbortFunc: Allow embedding program to handle fatal errors https://bugs.python.org/issue30560
Yes, this should be a feature of any redesigned embedding API.
I studied code of applications embedding Python. Most of them has to decode bytes strings to get wchar_t* to set home, argv, program name, etc. I'm not sure that they use the "correct" encoding, especially since Python 3.7 got UTF-8 Mode (PEP 540) and C locale coercion (PEP 538).
Unless you studied Windows-only applications embedding Python, _all_ of them will have had to decode strings into Unicode, since that's what our API expects. All of the Windows-only applications I know of that embed Python are closed source, and none are owned by Red Hat. I'm going to assume you missed that entire segment of the ecosystem :) But it also seems like perhaps we just need to expose a single API that does "decode this like CPython would" so that they can call it? We don't need a whole PEP or a widely publicised and discussed redesign of embedding to add this, and since it would solve a very real problem then we should just do it.
I tried to convert the source code of each project into pseudo-code which looks like C code used in CPython.
Thanks, this is helpful! My take: * all the examples are trying to be isolated from the system Python install (except Vim?) * all the examples want to import some of their own modules before running user code * nobody understands how to configure embedded Python :) Also from my own work with/on other projects: * embedders need to integrate native thread management with Python threads * embedders want to use their own files/libraries * embedders want to totally override getpath, not augment/configure it Cheers, Steve