Why? Python is able to load Python code at runtime, so one can use Python for configuration. A solution doesn’t need to go looking for problems.

...and yet Python people routinely fail to grasp this and end up writing ad-hoc config language interpreters on top of yaml anyway.

Granted the conveniences of Python syntax for code are mostly lost when trying to express tree structured data, and yaml flips that on its head.

(Mumble, grumble, something about s-expressions...)

That’s because it’s impossible to properly sandbox the config parsing. It’s also a horrible experience to debug configs.

But it’s still better than templating yaml.

People interested in configuring Python software in Python should look into Starlark. There are Python bindings for two versions of Starlark: Go (https://github.com/caketop/python-starlark-go) and Rust (https://github.com/inducer/starlark-pyo3). I used python-starlark-go for a time in a project that ran on x86-64 Linux and had no problems with it. (I stopped because my project's configuration turned out simpler than expected, so I switched to TOML.)

Worth noting that it is specifically CPython that has been called impossible to sandbox. (2014 discussion: https://news.ycombinator.com/item?id=8280053.) It may be possible to sandbox PyPy. PyPy has a sandboxing feature its website calls a "working prototype" (https://www.pypy.org/features.html#sandboxing). If someone invested in it—potentially a huge effort—it could plausibly become good enough for configuration. But, IMO, Starlark is a better choice here because it was designed for isolation from the start. If you wanted to invest in Python-as-config-for-Python, a good use of your time might be improving Starlark for Python.

Looks very interesting. Thanks for the pointer.

So true. One of the major config mgt utilities which shall remain nameless, (cough, Ansible, cough), is written in python but created an excrable POS config language build on YAML. At least Ant had the excuse that Java was not suitable for a config language. Will people never learn that building scripting languages on markup languages will inevitably end in tears?

Not uncommon to have a python program that loads external half-trusted configuration, that must be sandboxed in capabilities.

For in-house stuff, totally agree, just use the python code itself as the configuration.

That's a strange way to frame it, you don't have to support every language to be successful. World domination might not even be the project's goal.

And at the same time borrowing the name and file ending of Pythons object serialization protocol.

They start with Swift, Java, Kotlin and Go. That's already a big chunk of applications. Perhaps more will come in the future.

No C library sounds like a purposeful omission to slow down third party integrations.