Как стать автором
Обновить

Комментарии 14

На хабре уже упоминали: отличное решение — это просто использовать ConfigObj. Он и Юникод умеет, и валидацию, и значения по умолчанию, и конверсию типов, и вложенные секции.
а с тем, который просто config не сравнивали? я, правда, пока его использовал только в мелких «наколенных» скриптах, но пока нравится… нашел его, кажись, тоже на хабре…
ну судя по документации: вроде приятный парсер, но там свой синтаксис конфига. Как по мне, то он местами даже лучше чем ini-style, но непривычный.

cross-references — прикольно;
Кучи скобок — смотрятся немного стрёмно в конфиге, но напоминают синтаксис питона. Даже не знаю хорошо это или плохо
$` — напоминает sh
evaluating values — наверное удобно иногда, но редко. Лучше и безопаснее в коде как-то обрабатывать.

Чего не заметил (в сравнении с ConfigObj):
нет валидации конфигов и возможности создать темплейт для приведения к питоновским типам.
спасибо за совет, попробую посмотреть :)
Небольшое лирическое отступление.
В сообществе Python-программистов следует всеми правдами и неправдами продавливать YAML как основной формат конфигураций. А также агитировать за игнорирование PasteDeploy и PasteScript до тех пор, пока они не избавятся от «беспредела» в своём коде.
А существуют обоснованные аргументы в пользу YAML? Дайте ссылку, если вас не затруднит.
какие аргументы для вас будут обоснованными?
Ну возможно запись в блоге. Или обсуждение на каком-то форуме.
А вы как пришли к такому мнению?
Например, благодаря PEP 391 в Python 2.7 появился способ конфигурирования стандартного пакета логирования через словари. Примеры кофигурации представлены в YAML-нотации, а сам подход объявлен предпочтительным перед вариантом с ConfigParser-ом.

Про Paste. Я занимаюсь разработкой под Pylons, в котором PasteDeploy и PasteScript идут в качестве зависимостей. До того момента, как проект Pylons было решено забросить и начать разработку Pyramid, разработчики объявляли о намерении заменить Paste на самописный пакет Marco, в котором присутствовала возможность конфигурирования посредством YAML. Но с того момента проект успешно заглох. Переписка с разработчиками показала, что они не в большом восторге от Paste (а тому есть очень веские причины), но так как он «просто работает» и «это не высокоприоритетная задача», дорабатывать Marco в ближайшее время никто не собирается.
Когда я переводил свой проект на YAML-конфигурации без использования Paste, мне пришлось лезть и разбираться в его исходниках. Сказать, что Paste ужасен — ничего не сказать. Он изначально предлагает ущербный формат, без права выбора, и поверх этого строит свою неструктурированную кодовую базу, состоящую из хуков типа paste.deploy.converters и вложенных кусков посторонних пакетов (вроде CherryPyWSGIServer из пакета CherryPy).
В итоге, процесс конфигурирования более-менее сложного проекта с помощью Paste превращается в уродский набор инструкций на уровне python-кода вашего приложения.

Лично мне кажется, что INI прижился в среде Python-разработчиков только благодаря тому, что он очень давно существует в стандартной библиотеке (точно присутствовал уже в 1.6) и ему до недавнего времени не было абсолютно никаких альтернатив — не было других «парсеров из коробки». Но ситуация меняется. Станадртный парсер JSON, основанный на коде simplejson, появился только в версии 2.6. Дойдёт время и до включения PyYAML в стандартную поставку.
Я немного погуглил на эту тему: yaml парсер самый медленный во всех сравнениях. Плюс самый малораспространённый.
Вы же конфигурацию один раз во время инициализации приложения читатете. Зачем вам измерять преимущества формата по принципу скорости парсинга?
Параметр dict_type появился только в 2.6, поэтому инициализацию лучше заменить на:
def __init__(self, *args, **kwargs):
 ConfigParser.RawConfigParser.__init__(self, *args, **kwargs)
спасибо, поправил :)
Ну не знаю насчет решения; чтоб придумать более красивое и удачное решение, нужно какое-то более детальное проблемы (трейс?), а тут проблемы конкретной не обозначено, только «что-то иногда не работает» и какой-то кусок кода, который вроде бы как-то проблему решает.

вот это:
unicode(value)

не есть хорошо, т.к. преобразование будет проходить с непонятно какой кодировкой (ascii по дефолту?).

С кодировками-то все просто ведь, главное на каждом этапе понимать, с каким типом данных мы имеем дело (например, строка в utf8 или юникодная строка). Тут одна тонкость только есть — при конкатенации юникодных и неюникодных строк происходит неявное преобразование неюникодной строки в юникод, при этом используется дефолтная кодировка, что приводит к UnicodeEncodeError (особенно на win), т.к. эта кодировка часто ascii. Т.е. если сверху в файле написано «coding: utf8», и дальше объявлена константа на русском без u спереди, то вполне вероятно, что под nix все будет работать, а под win — неожиданно упадет. Выход — не складывать строки разных типов (str и unicode), а преобразовывать все в юникод пораньше.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории