Всегда ли вежливо помещать код в файл конфигурации Python?

Question

Одна из моих любимых функций в python - вы можете писать конфигурационные файлы на python, которые очень просты для чтения и понимания. Если вы наложите несколько границ на себя, то можете быть уверены, что непитонисты точно поймут, что вы имеете в виду, и будут в полной мере способны перенастроить вашу программу.

Мой вопрос: что это за границы? Моя личная эвристика была

1. Избегайте контроля потока. Нет функций, циклов или условий. Их не будет в текстовом конфигурационном файле, и люди не ожидают, что их поймут. В целом, вероятно, не должно иметь значения порядок, в котором выполняются ваши операторы.
2. Придерживайтесь буквальных заданий. Методы и функции, вызываемые для объектов, сложнее продумать. Все, что скрыто, будет беспорядком. Если что-то должно произойти с вашими параметрами, измените их интерпретацию.
3. Ключевые слова языка и обработка ошибок прямо.

Наверное, я спрашиваю об этом, потому что я столкнулся с ситуацией с моим конфигурационным файлом Django, где кажется полезным нарушить эти правила. Мне это нравится, но я чувствую себя немного виноватым. По сути, мой проект разворачивается с помощью svn checkouts на пару разных серверов, которые не будут настроены одинаково (некоторые будут использовать общую базу данных, а некоторые - нет). Итак, в конце бросаю крюк:

try:
    from settings_overrides import *
    LOCALIZED = True
except ImportError:
    LOCALIZED = False

где settings_overrides находится на пути к питону, но за пределами рабочей копии. Что вы думаете об этом примере или о границах конфигурации Python в целом?

Answer 1

Существует вики-страница Django, которая адресована именно тому, о чем вы просите. http://code.djangoproject.com/wiki/SplitSettings

Не изобретать велосипед. Используйте configparser и файлы INI. Файлы Python легко взломать тем, кто не знает Python.

Answer 2

Я думаю, что это аргумент боли против удовольствия.

Это не неправильно - помещать код в конфигурационный файл Python, потому что все это допустимый Python, но это означает, что вы можете запутать пользователя, который приходит, чтобы изменить конфигурацию приложения. Если вас это беспокоит, связывайте его с комментариями, в которых примерно объясняется, что он делает, и что пользователь не должен его редактировать, лучше отредактируйте файл settings_overrides.py.

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

LOCALIZED = False

try:
    from settings_overrides import *
except ImportError:
    pass

А в вашем файле settings_overrides.py:

LOCALIZED = True

... Если ничего, кроме как прояснить, что делает этот файл ... То, что вы там делаете, разделяет переопределения на два места.

Answer 3

Ваша эвристика хороша. Правила составлены таким образом, что границы устанавливаются и нарушаются только тогда, когда это явно намного лучшее решение, чем альтернатива.

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

Я не думаю, что в этом случае альтернатива настолько плоха, что нарушение правил имеет смысл ...

-Adam

Answer 4

Настройки в виде кода также представляют угрозу безопасности. Вы импортируете свой «конфиг», но в действительности вы выполняете любой код в этом файле. Поместите конфигурацию в файлы, которые вы анализируете первыми, и вы можете отклонить бессмысленные или вредоносные значения, даже если это больше для вас. Я написал об этом в декабре 2008 года.

Answer 5

В качестве общей практики см. Другие ответы на странице; Все это зависит. Однако специально для Django я не вижу ничего принципиально неправильного в написании кода в файле settings.py ... в конце концов, файл настроек - это IS-код :-)

Документы Django о самих настройках говорят:

Файл настроек - это просто модуль Python с переменными уровня модуля.

И приведите пример:

assign settings dynamically using normal Python syntax. For example:
MY_SETTING = [str(i) for i in range(30)]