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
- 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.
- 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.
- 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?
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.