Комментарии 14
На хабре уже упоминали: отличное решение — это просто использовать ConfigObj. Он и Юникод умеет, и валидацию, и значения по умолчанию, и конверсию типов, и вложенные секции.
а с тем, который просто config не сравнивали? я, правда, пока его использовал только в мелких «наколенных» скриптах, но пока нравится… нашел его, кажись, тоже на хабре…
ну судя по документации: вроде приятный парсер, но там свой синтаксис конфига. Как по мне, то он местами даже лучше чем ini-style, но непривычный.
cross-references — прикольно;
Кучи скобок — смотрятся немного стрёмно в конфиге, но напоминают синтаксис питона. Даже не знаю хорошо это или плохо
$` — напоминает sh
evaluating values — наверное удобно иногда, но редко. Лучше и безопаснее в коде как-то обрабатывать.
Чего не заметил (в сравнении с ConfigObj):
нет валидации конфигов и возможности создать темплейт для приведения к питоновским типам.
cross-references — прикольно;
Кучи скобок — смотрятся немного стрёмно в конфиге, но напоминают синтаксис питона. Даже не знаю хорошо это или плохо
$` — напоминает sh
evaluating values — наверное удобно иногда, но редко. Лучше и безопаснее в коде как-то обрабатывать.
Чего не заметил (в сравнении с ConfigObj):
нет валидации конфигов и возможности создать темплейт для приведения к питоновским типам.
спасибо за совет, попробую посмотреть :)
Небольшое лирическое отступление.
В сообществе Python-программистов следует всеми правдами и неправдами продавливать YAML как основной формат конфигураций. А также агитировать за игнорирование PasteDeploy и PasteScript до тех пор, пока они не избавятся от «беспредела» в своём коде.
В сообществе 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 в стандартную поставку.
Про 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)
Ну не знаю насчет решения; чтоб придумать более красивое и удачное решение, нужно какое-то более детальное проблемы (трейс?), а тут проблемы конкретной не обозначено, только «что-то иногда не работает» и какой-то кусок кода, который вроде бы как-то проблему решает.
вот это:
не есть хорошо, т.к. преобразование будет проходить с непонятно какой кодировкой (ascii по дефолту?).
С кодировками-то все просто ведь, главное на каждом этапе понимать, с каким типом данных мы имеем дело (например, строка в utf8 или юникодная строка). Тут одна тонкость только есть — при конкатенации юникодных и неюникодных строк происходит неявное преобразование неюникодной строки в юникод, при этом используется дефолтная кодировка, что приводит к UnicodeEncodeError (особенно на win), т.к. эта кодировка часто ascii. Т.е. если сверху в файле написано «coding: utf8», и дальше объявлена константа на русском без u спереди, то вполне вероятно, что под nix все будет работать, а под win — неожиданно упадет. Выход — не складывать строки разных типов (str и unicode), а преобразовывать все в юникод пораньше.
вот это:
unicode(value)
не есть хорошо, т.к. преобразование будет проходить с непонятно какой кодировкой (ascii по дефолту?).
С кодировками-то все просто ведь, главное на каждом этапе понимать, с каким типом данных мы имеем дело (например, строка в utf8 или юникодная строка). Тут одна тонкость только есть — при конкатенации юникодных и неюникодных строк происходит неявное преобразование неюникодной строки в юникод, при этом используется дефолтная кодировка, что приводит к UnicodeEncodeError (особенно на win), т.к. эта кодировка часто ascii. Т.е. если сверху в файле написано «coding: utf8», и дальше объявлена константа на русском без u спереди, то вполне вероятно, что под nix все будет работать, а под win — неожиданно упадет. Выход — не складывать строки разных типов (str и unicode), а преобразовывать все в юникод пораньше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ConfigParser и Unicode