config-файлы - способы их организации в программе на Python

Если не предполагается редактировать конфиг руками, то можно заюзать pickle или аналоги.

Если предполагается - можно заюзать execfile или import. Это же питон;-)

Организация зависит от задачи. У меня обычно словарь - в эту идеологию лезет фсе.

У меня обычно словарь - в эту идеологию лезет фсе.

Ok. Поскольку я делаю opensource-приложение, это наверное будет самым эффективным. Просто import config :) Я про него что-то забыл :)

Странно, обычно в программах на динамических языках конфиг - просто скрипт на том же языке. Зачем создавать парсеры, если может распарсить интерпретатор?

в новых программах стараюсь использовать yaml. в отличие от xml, он человекоредактируемый.

эх... сделали бы давно хоть какой-нибудь стандарт и убрали бы помойку в /etc...

эх... сделали бы давно хоть какой-нибудь стандарт и убрали бы помойку в /etc...

Этих стандартов уже давно сделали как грязи. Выбирай любой.

Организовать в виде .py-модуля. Формат хранения от словаря до каскада вложенных кортежей. xml и прочие костыли-то зачем тянуть в проект?

Ну в зависимости от данных. В 99% случаев за глаза хватает «2. Список списков ([section] name=value) - ini» (Из него кстати прекрасно делается и иерархия с уровнем вложение больше 2)

Если предполагается - можно заюзать execfile или import. Это же питон;-)
Зачем создавать парсеры, если может распарсить интерпретатор?

Может все-таки не надо, a?
Вдруг там будет «os.system('rm -f /*')» или другой код, который исполняется при импорте?

Вдруг там будет «os.system('rm -f /*')»

Хитрый план.

Paranoid version:

from ast import NodeVisitor, parse, literal_eval

class Boo(NodeVisitor):
    def process(self, source):
        self.data = {}

        self.visit(parse(source))
        return self.data

    def visit_Assign(self, node):
        self.data[node.targets[0].id] = literal_eval(node.value)


print Boo().process('''
string = 'dsdfdf'
number = 5
dict = {'aaa':1, 'bbb':2}
''')

Только чем он лучше конфигпарсер? :)

Тем что отсутствие запятой в конфиге угробит весь конфиг?
Да и программа может менять конфиг, а это с питонячим кодом будет фиговато.

Тред не читал, люблю этот.

Только чем он лучше конфигпарсер?

Нет дурацких секций, есть типизация и сложные значения (списки и словари).

Да и программа может менять конфиг

Гм. Как ConfigParser здесь поможет?

Нет дурацких секций

Вот это жаль.

Как ConfigParser здесь поможет?

config = configparser.ConfigParser()
....
with open('example.ini', 'w') as configfile:
    config.write(configfile)

Изменил, записал изменения.

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

Например, писалка/читалка конфигов в snaked умеет иерархию конфигов с расширением родительских значений и комментарии к параметрам.

В сложных случаях обычно делаю несколько конфигов, ибо все яйца в 1 корзине плохая примета, да и проще в обслуживании получается.

XML

как единственно понятный людям и удобочитаемый формат

XML

как единственно понятный людям и удобочитаемый формат

...только,

• при жёстком декларировании структуры .xml
• при жёстком соблюдении порядка следования секций
• при использовании редакторов с подсветкой синтаксиса (gvim file.xml)
• при наличии инструмента сравнения текстовых файлов (gvimdiff file1.xml file2.xml).

при жёстком декларировании структуры .xml
при жёстком соблюдении порядка следования секций

by design

ибо все яйца в 1 корзине плохая примета, да и проще в обслуживании получается.

Можно просто посмотреть - как в других проектах делается. :)

Эммм... не понял, что конкретно ты хотел сказать? Что так нельзя делать? :)
Кстати, тема помечена как решенная, что решил то? :)