и я согласен, любой формат можно использовать не по назначению и/или превратить его в кошмар;)

Я привык не усложнять себе жизнь редактированием через sed.

ты удивишься;)

Ты привык извращаться? )

Разные интерфейсы редактирования человеком. Не то же самое.

так ini для редактирования человеком, в том то и дело

Ты привык извращаться? )

я привык использовать инструменты по назначению

Ага. Тогда, наверное, понимаешь, что извращаться sed'ом это не совсем по назначению.

я вот только вчера сделал коммит sed-ом в мой рабочий проект за минуту. уверен, любое ide с его gui потребовалы больше времени

так ini для редактирования человеком, в том то и дело

Мне, как человеку, хотелось плакать, конфигурируя что-то в ini. :)

это при том, что я код редактирую только в ide, без всяких ущербных редакторов

Мне, как человеку, хотелось плакать, конфигурируя что-то в ini. :)

ну тут надо разбираться что такое "что-то"

Пример с головы: [blabla] admins = vasya А второй админ через запятую? Через пробел? Другой разделитель? А если я не угадаю, то моего админа будут звать "vasya,petya".

Используйте ущербные редакторы, они полезны и позволяют экономить время. )

Пример с головы: [blabla] admins = vasya А второй админ через запятую? Через пробел? Другой разделитель? А если я не угадаю, то моего админа будут звать "vasya,petya".

можешь и через пробел и через запятую, такой ini но это мелкая проблема формата, которая понятна и этому легко убучается даже девочка "убейти меня я дура", но вот json-у ее научить невозможно

надо смотреть со стороны пользователя, а не человека, который знает что такое bnf

Не, не могу. Потому что разработчик впилил value.split(" ").

Не, не могу. Потому что разработчик впилил value.split(" ").

чо то мы разными configparser пользовались, похоже

https://docs.python.org/3/library/configparser.html#supported-datatypes

да, видимо я сам хачил;)

ну, значит не надо использовать ini уже для списков;)

но вот { "blabla": { "admins": ["vasya"] } } это перебор, имхо

А что оптимально?

При условии, что я как пользователь хочу точно знать, как не ошибиться.

Но можно для начала и без этого условия. )

При условии, что я как пользователь хочу точно знать, как не ошибиться.

гуй, опция Preferences

Ну это уже нечестное ведение диалога. )

а если файлик, то дока и ini на пять строк. обычно достаточно

это для пользователя

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

на совпадение я использовал ини для список прямо вчера

там довольно очевидно что через запятую оно )

Где "там"?

ну т.е. достаточно один раз это юзеру сказать

http://dev.utek.pl/2013/ignoring-tables-in-alembic/

а вот тебе это и сказали, в доке

:)

Еще раз: ini фиксирует формат только примитивных значений. Все остальное – полет фантазии разработчика. И прелесть вашего любимого ini в том, что любую ошибку он тихо схавает.

в общем я за ини либо ямл (в зависимости от задачи)

ну да, а ты напишешь после валидации значений, у меня такого нет

а yaml – надмножество json, и я уже могу сказать, что вы предвзяты к json )

Еще раз: ini фиксирует формат только примитивных значений. Все остальное – полет фантазии разработчика. И прелесть вашего любимого ini в том, что любую ошибку он тихо схавает.

ошибку синтаксиса. ошибка синтаксиса - далеко не любая. по опыту, главные ошибки юзеров не в синтаксисе:)

Я о том же.

а yaml – надмножество json, и я уже могу сказать, что вы предвзяты к json )

да по фигу кто чье множество. суть в том, что yaml руками редактирвоать проще

Любые ошибки после = в ini съедаются и обнаруживаются очень поздно.

Любые ошибки после = в ini съедаются и обнаруживаются очень поздно.

в данном случае, я не понимаю что такое поздно.

да по фигу кто чье множество. суть в том, что yaml руками редактирвоать проще

Именованные сущности в yaml – тоже нормально? )

юзер стори: 1. написать конфиг 2. запустить программу 3. получить сообщение от программы что не так в конфиге

тут нету поздно или рано, оно одновременно

для пользователя

в данном случае, я не понимаю что такое поздно.

Поздно, это когда все развернул и увидел, что оно не работает правильно из-за своего кривого значения.

Именованные сущности в yaml – тоже нормально? )

не понимаю по-русски

Поздно, это когда все развернул и увидел, что оно не работает правильно из-за своего кривого значения.

см. юзерстори

не понимаю по-русски

Сказано, что yaml редактировать проще. Отвечаю: yaml сложнее по определению.

прелесть ini в том, что ты можешь юзеру точно сказать почему что-то не так, в терминах бизнес логики

см. юзерстори

Смотрю. Валидация не словит мою ошибку в разделителе.

И она вообще ничего не словит, ибо все значения в ini – строки.

Сказано, что yaml редактировать проще. Отвечаю: yaml сложнее по определению.

не надо передергивать. yaml сложнее в смысле позволяет больше. и как раз благодаря этому его проще творить. он позволяет делать вид удобным для редактирвоания

Смотрю. Валидация не словит мою ошибку в разделителе.

значит ты ее плохо написал

А я вообще писать уже написанное кем-то другим мало люблю. _

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

не надо передергивать. yaml сложнее в смысле позволяет больше. и как раз благодаря этому его проще творить. он позволяет делать вид удобным для редактирвоания

Я не передергиваю, я видел yaml конфиги.

А я вообще писать уже написанное кем-то другим мало люблю. _

никто не писал логику твоего приложения до тебя

Логику парсинга списков, приведения типов, whatever уже написали за меня авторы модуля json. Мне осталось проверить лишь бизнес-логику, а корректность описания вот этих вот строчек в ini.

*а не

людей ни то, ни другое не устраивает полностью еще один вариант https://github.com/hashicorp/hcl (с описанием мотивации)

Конечно, если вам нравится снова и снова парсить все это – ваше право, если вам не запрещают. Но тогда: предусматривайте все возможные косяки в значениях и обучайте всех остальных любителей ini-файлов делать так же, чтобы люди не бились головой.

еще раз, не хватает ini - не используй

Мне жалко времени на велосипедостроение.

да, списки уже перебор

ноиногда лучше сделать сплит, чем мучить обезьянок json-ом

Так речь-то была о чем? Посмотрите выше, там было что-то про вложенные конфиги и что в ini конфигурить было бы лучше.

не, там про yaml :)

Без нарушения общности. )

ну и то что json для этого неудобен

просто вот он неудобен

хер с нми с ini

но json - это не формат для конфигов

он для этого не подходит.

.

:)

Это таки предубеждение. Если уже речь о том пошла – то плохо все.

да, возможно:)

жизнь говно, так то

Yaml выносит мозг из-за очень похожих спецсимволов в разных конструкциях, а если он автосгенерирован, то в нем появляются все его прелести, от которых плакать хочется даже больше, чем от ini. )

Короче, все отстой, давайтн сделаем свой стандарт. :)

Yaml выносит мозг из-за очень похожих спецсимволов в разных конструкциях, а если он автосгенерирован, то в нем появляются все его прелести, от которых плакать хочется даже больше, чем от ini. )

вот, автосгенерированный конфиг - это срань в любом случае.

возвращаемся к моим словам о хранении конфигурации и интерфейсе для пользователя

Ну не скажи. json.dumps(..., indent=2) или ConfigParser.save(...) еще вменяемы.

Чего не скажешь о том, что делает PyYAML.

я не пробовал.

но вот знаю, что форматтер в Eclipse меня устраивает

у меня весь ansible проект им отформатирован

я тут программирую на yaml просто;)

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

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

да при чем тут? не надо поганить что пользователь написал, хочешь заперсистить в ФС, делай как хочешь, но не туда, где пользователь редактирует

Это намек, что интерфейса без конфига может вообще не быть.

Сервис просто не запуститься, так скажем.

*запустится

конфиг и есть интерфейс, внезапно