# FR: Allow private runtime config to enable extending without breaking the \`PyConfig\` ABI

**URL:** <https://discuss.python.org/t/fr-allow-private-runtime-config-to-enable-extending-without-breaking-the-pyconfig-abi/18004>\
**Category:** Core Development\
**Created:** [August 5, 2022, 10:32pm UTC](https://discuss.python.org/t/fr-allow-private-runtime-config-to-enable-extending-without-breaking-the-pyconfig-abi/18004 "2022-08-05T22:32:10Z")\
**Posts on this page:** 1\
**Showing post:** 24

<div class="post-metadata">

**Author:** ![vstinner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/vstinner/32/15130_2.png) [@vstinner](https://discuss.python.org/u/vstinner)\
**Post date:** [October 2, 2023, 9:33am UTC](https://discuss.python.org/t/fr-allow-private-runtime-config-to-enable-extending-without-breaking-the-pyconfig-abi/18004/24 "2023-10-02T09:33:35Z")

</div>

> [@encukou](#):
>
> FWIW, type & module slots have the same issue. We’re designing need a type-safe, forward compatible way of setting and getting “properties” at the C level; whatever we come up with should feel consistent with the future API for any other slots.

The difference between an API to configure Python initialization and an API to access PyTypeObject is that we can make some trade-offs in terms of performance overhead for the config API: it’s ok to use strcmp(). For PyTypeObject, nope, it must be as fast as possible.

> [@encukou](#):
>
> We’ll eventually also need getters, such as: `PyInitConfig_GetInt`

Are you proposing to get configuration before the initialization, or after `Py_InitializeFromInitConfig `()?

Before, is it really useful? If you want a specific value, just set it, no?

When I designed PEP 587, I proposed a way to: (1) read the config which included the “Path Configuration”, (2) modify the config including “adding a path to module\_search\_paths”, (3) “write” the config (initialize Python). Since Python 3.8, this part changed: the path configuration is no longer “read” before the actual Python initialization, it’s only computed “after” Python initialized.

After Python initialization, I am not sure if PyInitConfig would be a good fit to read the current “initialization” state.

There were long discussions about exposing PyConfig which went nowhere (no API was added):

- [Expose \_PyCoreConfig structure to Python · Issue #78100 · python/cpython · GitHub](https://github.com/python/cpython/issues/78100)
- [Allow efficient read access to PyConfig options · Issue #99872 · python/cpython · GitHub](https://github.com/python/cpython/issues/99872)
- [[C API] Deprecate Global Configuration Variables like Py\_IgnoreEnvironment · Issue #93103 · python/cpython · GitHub](https://github.com/python/cpython/issues/93103)

Problem: private APIs to access PyConfig are gone (moved to the internal C API) in Python 3.13.

Maybe we need a new stable ABI / API to get “runtime” configuration, but it would have no “config” argument, since values would be read from “Python”:

- PyConfig\_GetInt(name: str)
- PyConfig\_GetStr(name: str)
- etc.

For options accessed most commonly, we can consider adding specialized API to avoid name string, to provide best performance. I’m thinking about Cython which needs to access a few config options frequently.

Notice the difference between “init config” (before Python is “created”) and “config” (runtime config, while Python is running).

@encukou: Would PyConfig\_GetInt() fit your use cases? Or do you think that `PyInitConfig_GetInt()` _is_ needed?

---

_[View the full topic](https://discuss.python.org/t/fr-allow-private-runtime-config-to-enable-extending-without-breaking-the-pyconfig-abi/18004)._