On Wed, 11 Nov 2020 at 09:59, Victor Stinner email@example.com wrote:
If you embed Python in Python, I would like your opinion on https://bugs.python.org/issue42260 issue which adds a way to configure the Python initialization in Python.
I'm looking for feedback from people who embed Python and have issues to configure Python as they wish.
Simple example (just to show how the API would look like) setting the the bytes_warning option:
import _testinternalcapi import sys
assert sys.flags.bytes_warning == 0
config = _testinternalcapi.get_config() # Copy PyConfig config['bytes_warning'] = 1 # regular Python dict _testinternalcapi.set_config(config) # Update PyConfig and sys
assert sys.flags.bytes_warning == 1
The example already works in the current master branch!
I remember the work you put in getting runtime reconfiguration working again for 3.7.1, so it's cool to see that capability maturing even further.
Nick Coghlan recently withdrew his PEP 432 since PEP 587 was rejected.
It made me sad :-(
Seeing the huge improvements that have been made to the startup management code since I first wrote PEP 432 makes me happy.
Sure, the technical details aren't exactly what I first envisioned, but I never expected those to survive exactly as written - the problem is simply too big and too complex for my first guess at a plausible way of fixing it to be exactly what we ended up doing :)
- [WIP] Rewrite Modules/getpath.c (1600 lines of C code) to
Lib/_getpath.py (700 lines of Python code)
See https://bugs.python.org/issue42260 for the work-in-progress.
Wow, it's one thing to suggest this as a desirable goal, and another to see it so close to actually happening! Very cool :)
From a practical point of view, executing Python code to initialize Python requires freezing this code as a frozen module (as I did for _getpath.py in my PR). I don't know if it's easy to do that in an application embedding Python right now.
It's still not trivial, but it's easier now that we do it in the standard library (since it means there is reference code to copy).
My remaining problem is that my PR changes PyConfig_Read(): it no longer computes the Python Path Configuration, since it is now implemented in Python. IMO it's an acceptable drawback compared to the benefit of these new features.
Even though I wouldn't expect it to be controversial, it's probably worth writing up this migration of the path configuration code from C to Python as a PEP, along the lines of what we suggested in the last part of the PEP 432 withdrawal notice.
The change has the potential to produce unexpected consequences for folks inadvertently relying on the quirks of the current implementation, and having the PEP there to cover the technical details means we can provide more information than could be squeezed into a single paragraph in the What's New document.