[Python-Dev] RFC: PEP 587 "Python Initialization Configuration": 2nd version

Steve Dower steve.dower at python.org
Mon May 13 12:28:36 EDT 2019


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


More information about the Python-Dev mailing list