Adding new options is fine, but I’m not sure if removing options would be acceptable? Should we support deprecated/removed options forever? Or can we just fail with an error?

I don’t recall examples of removed configuration options. My hope is that legacy_windows_fs_encoding and legacy_windows_stdio options will go away at some point, but I’m not sure about it.

I wasn’t sure about that, I tried to explain that the limited API is optional. I will try to rephrase that.

The latter. Apparently, my phrasing is confusing. I mean that since PEP 587 was implemented in Python 3.8, some APIs started to be deprecated.

The Backward Compatibility section says that PEP 587 PyConfig API is still supported, there is no plan to deprecate it. For me, it’s almost a different use case (different constraints).

PyInitConfig is an opaque structure, it’s different. I don’t see how we can reduce the number of structures without affecting the backward compatibility.

That would be incompatible with the limited C API, since PyConfig and PyPreConfig members are not part of the limited C API. I would prefer to avoid that.

PyConfig is part of PyInterpreterState, whereas PyPreConfig is part of PyRuntimeState. The PyStatus is only used to report failures to the Py_InitializeFromConfig() caller, it shouldn’t be stored at runtime. Also, changing these structures might affect the backward compatibility.

When PyConfig members are only used to initialize configuration options, PyConfig_Get() gets the runtime configuration option value, not the PyInterpreterState.config value which was used for initialization.

For example, sys.path is always different than PyConfig.module_search_paths, since the site module is executed after sys.path is initialized from PyConfig.module_search_paths. PyConfig_Get("module_search_paths") gets sys.path.

Some options are not copied outside PyConfig, such as PyConfig.tracemalloc. Some options are copied but cannot be modified at runtime.

I think that it’s more useful to use what the user gets/sees at runtime, rather than what was used to initialize Python. That’s why it’s called PyConfig_Get() and not PyInitConfig_Get().

I prefer to write the smallest API, unless a strong use case to justify adding more options.