На питоне можно писать так чтобы была тонна логики и магия. И в одноу строчку. Но ты так не делаешь. С конфигами тоже самое. Если ты внёс много магии, это сам дурак. Если ты внёс щепотку магии которая облегчает работу, то это очень хорошо

yaml прекрасен, и в питоне и ансамбле (он весь yaml) только им и пользуюсь.
За пределами моей делянки приходится искать компромиссы :(

за исключением людей

А потом ещё щепотку, а потом ещё, а потом ой, не конфиг, а кролик в шляпе...

Как только тебе потребуется организовать наследование конфигов с поддержкой вложенных словарей и списков, код, делающий это, будет велосипедировать yaml

ну на то и нужны коде ревью.. Рефакторинг и другие страшные слова.

Вот пример... Есть у тебя параметр bitrate, который пусть равен 9600 по умолчанию.
Где ты определяешь это магическое число 9600? В коде или в конфиге?

не спорю
но в многих случаях этого не нужно ¯\_(ツ)_/¯

Если оно настраиваемо, то в конфиг, числом, если нет, то можно и в код констатой

конечно мы говорим про настраиваемые значения

Тогда в конфиг

Что будет если в конфиге этого параметра не будет совсем?

Про базовый и override конфиги я у вас и научился и принёс везде, куда мог. Оч благодарен.

базовый это не очень хорошее слово, но именно его я и использовал раньше.
Базовый конфиг, этот тот конфиг который идет вместе с приложением. И который пишет только разработчик, куда вносятся все дефолтные значения и в котором определена вся структура конфига.
В нём описываются комментарии к полям, возможные значения и т.д.
Этот конфиг поставляется в RPMке / докере или еще как то так ВМЕСТЕ с остальными исходными файлами.
При этом тестеры / юзеры / админы могут посмотреть его, но не должны его менять.
Когда кто то делает в коде дефолтное значение, а в конфиге в коментариях или в самом конфиге дублирует это значение  — это больше зло. Дублирование это одна из частых причин ошибок.

А есть конфиг инсталяции. Где меняются ТОЛЬКО нужные параметры.

Я помню времена, когда мы приходилось готовить конфиги в тысячи строк, которые являлись копипастами других конфигов. Это прям злое зло. У нас прод падал из-за того что в инсрукциях писали что надо обновить одно значение, а в бренче который деплоился оно должно было другим. И бедные админы эти конфиги с большим трудом поддерживали на серваках (они даже в gitе не лежали).
С тех давних пор у меня есть не зыблемое правило, что любой конфиг должен лежать в gitе и автоматически деплоиться. Никаких ручных изменений на серваках..

Вот прям HOCON. Еще + поддержка юнитов: байты, секунды, fallback к переменным окружения, инклюды. И в нем можно писать очень просто, типа key=value, а можно вложенно как в json/yaml. https://github.com/chimpler/pyhocon

хокон прикольно

но не везде есть достойный пакет для использования

Про типы данных и конфиги я для себя решил, что это ничем не отличается от входящих параметров web-API вызова от клиента. И работать с этим надо точно так же:
- надо в коде описать схему параметров для каждого отдельного приложения в проекте;
- схема определяет типы данных, ограничения, валидацию, дефолтные значения, хелп-тексты и всё остальное, что можно описать в разных реализациях схем/десериализаторах;
- пишется "бекенд", который читает конфиг от куда либо: ini, yaml, xml, json или из базы данных и применяет к ним схемы для десериализации и валидации. Это почти полностью решает проблему с типами - если в схеме требуется строка, то десериализатор вернёт всегда строку, даже если ему подсунули число.
- по красоте можно написать генератор документации, который по схемам сгенерит доку для конфига (в схеме есть уже всё, даже хелп-тексты).
- ещё более крутая красота - автоматом генерить админку для конфига на основе схем. Это полезно когда конфиги лежат в базе, хотя и редактировать файлы админкой, никто не мешает.

Может кто видел dconf в линуксах. Там как мне кажется подобная штука - GUI редактор явно от куда-то берёт схемы для настроек где есть всё и описание и типы и всё остальное.

угу, только я свой формат придумал больше 10 лет назад..
у этого хомла, на первый взгляд слишком много скобочек, хотя может можно и без них.. надо разбираться