I dislike having to do that, but I had to make a last minute change in my PEP 587 "Python Initialization Configuration" to allow to modify the structure in the future without breaking the backward compatibility. I added a "struct_size" field to PyPreConfig and PyConfig:
PyConfig config; PyStatus status = PyConfig_InitPythonConfig(&config); ...
must now be written:
PyConfig config; config.struct_size = sizeof(PyConfig); PyStatus status = PyConfig_InitPythonConfig(&config); ...
At the beginning, I used a private "_config_version" field which was initialized statically by a macro. But it was decided to replace macros with functions. I only noticed today that the conversion to function broke the API/ABI future compatibility.
PyConfig_InitPythonConfig() got uninitialized memory and didn't know the size of the config variable.
With my change, the function now requires the "struct_size" field to be set, and so it can support internally different versions of the PyConfig structure.
Storing the structure size directly in the structure is a common practice in the Windows API which is a good example of long term ABI compatibility.
By the way, last week, Pablo Galindo Salgado reported to me a regression in PyInstaller caused by the implementation of my PEP.
I fixed different issues related to the "Path Configuration" (sys.path in short), but I also added a lot of tests for this code. Previously, there was simply no test on the path configuration!
I added a lot of comments to the C code, and I completed the public documentation: https://docs.python.org/dev/c-api/init_config.html#path-configuration
Please test the incoming Python 3.8.0rc1 release with your project if you embed Python into your application. Please test also projects like PyInstaller, PyOxidizer, etc.
Note: PyInstaller requires my fix for 3.8 (not merged yet): https://github.com/pyinstaller/pyinstaller/pull/4440