Потенциальным «минусом» подхода с использованием файлов Python является то, что ваш пользователь может поместить в файл произвольный код, который будет выполняться в контексте вашего приложения. Как указывает С.Лотт в комментариях к этому ответу (когда я был несколько более настойчивым в своем предупреждении), это обычно не проблема, потому что пользователь (или хакер) обычно все равно будет иметь доступ ко всему исходному коду и может внести любые желаемые изменения.
Однако я, конечно, могу представить себе ситуации, в которых такой подход может привести к появлению новой дыры в безопасности, например, когда основные файлы сценариев доступны для записи только системному администратору, а файл конфигурации для каждого пользователя является единственным файлом, редактируемым конечный пользователь. Если вы не уверены, что ваш код никогда не будет работать в такой среде, я бы не рекомендовал модульный подход Python. Существуют веские причины, по которым «не выполнять код, предоставленный вам пользователями», широко считается лучшей практикой.
Выполнение файла конфигурации также затрудняет обработку ошибок. Если пользователь вводит синтаксическую ошибку, вы захотите ее перехватить, и вы можете легко сделать это, бросив try
вокруг вашего import
, но ничего после ошибки не будет выполнено. В конфигурационном файле, как правило, анализ продолжается со следующей строки, поэтому пользователь пропустит максимум одну настройку вместо (скажем) половины из них. Существуют способы заставить работать модуль Python больше похожим на файл конфигурации (вы можете прочитать файл как текст и, например, exec()
в каждой строке), но если вам вообще придется выполнять какую-либо работу, его становится проще использовать ConfigParser
.
Если, несмотря на все это, вы все еще хотите использовать синтаксис Python в своем конфигурационном файле, вы можете использовать модуль ast
(см. Функцию literal_eval()
).