Is it ever polite to put code in a python configuration file?

Question

One of my favorite features about python is that you can write configuration files in python that are very simple to read and understand. If you put a few boundaries on yourself, you can be pretty confident that non-pythonistas will know exactly what you mean and will be perfectly capable of reconfiguring your program.

My question is, what exactly are those boundaries? My own personal heuristic was

1. Avoid flow control. No functions, loops, or conditionals. Those wouldn't be in a text config file and people aren't expecting to have understand them. In general, it probably shouldn't matter the order in which your statements execute.
2. Stick to literal assignments. Methods and functions called on objects are harder to think through. Anything implicit is going to be a mess. If there's something complicated that has to happen with your parameters, change how they're interpreted.
3. Language keywords and error handling are right out.

I guess I ask this because I came across a situation with my Django config file where it seems to be useful to break these rules. I happen to like it, but I feel a little guilty. Basically, my project is deployed through svn checkouts to a couple different servers that won't all be configured the same (some will share a database, some won't, for example). So, I throw a hook at the end:

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

where settings_overrides is on the python path but outside the working copy. What do you think, either about this example, or about python config boundaries in general?

Answer 1

There is a Django wiki page, which addresses exactly the thing you're asking. http://code.djangoproject.com/wiki/SplitSettings

Do not reinvent the wheel. Use configparser and INI files. Python files are to easy to break by someone, who doesn't know Python.

Answer 2

Your heuristics are good. Rules are made so that boundaries are set and only broken when it's obviously a vastly better solution than the alternate.

Still, I can't help but wonder that the site checking code should be in the parser, and an additional configuration item added that selects which option should be taken.

I don't think that in this case the alternative is so bad that breaking the rules makes sense...

Answer 3

I think it's a pain vs pleasure argument.

It's not wrong to put code in a Python config file because it's all valid Python, but it does mean you could confuse a user who comes in to reconfigure an app. If you're that worried about it, rope it off with comments explaining roughly what it does and that the user shouldn't edit it, rather edit the settings_overrides.py file.

As for your example, that's nigh on essential for developers to test then deploy their apps. Definitely more pleasure than pain. But you should really do this instead:

LOCALIZED = False

try:
    from settings_overrides import *
except ImportError:
    pass

And in your settings_overrides.py file:

LOCALIZED = True

... If nothing but to make it clear what that file does.. What you're doing there splits overrides into two places.

Answer 4

As a general practice, see the other answers on the page; it all depends. Specifically for Django, however, I see nothing fundamentally wrong with writing code in the settings.py file... after all, the settings file IS code :-)

The Django docs on settings themselves say:

A settings file is just a Python module with module-level variables.

And give the example:

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

Answer 5

Settings as code is also a security risk. You import your "config", but in reality you are executing whatever code is in that file. Put config in files that you parse first and you can reject nonsensical or malicious values, even if it is more work for you. I blogged about this in December 2008.