I'm a Lead Technical Artist at CCP Games in Iceland, where I work on EVE Online. I am passionate about constantly evolving tools, pipeline, and the people and teams that build them. I believe the best way we can improve ourselves is by engaging with our fellow developers, so I founded www.tech-artists.org. Rob is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. You can read more from them at their website. View Full User Profile

Why? Python and Config Files

06.27.2012
| 2578 views |
  • submit to reddit

I’ve never understood why people design systems in python to use config files. IMO there are two types of data and we can handle them both in dead simple ways:

First: Read/write data, like UI/user preferences. I say, just use python dictionaries, and serialize them however the hell you want (json, yaml, pickle, cPickle, I don’t care). I don’t understand why anyone would build anything more complex (except maybe a wrapper over this functionality), and especially why anyone would bother using a non-serialized format like ini or cfg. Can there be a good reason?

Second: Read-only data, like application configuration (nothing that is edited by your app). This, too, is very commonly in config files with special like xml or ini. Well in this case I say, why bother even with serialized data at all? Just make it code! This data, by definition, does not have to be statically known and serialized, it is only needed at runtime. So why not make it a python module, have your code import/exec the python file, and access attributes from the python module? There’s a good deal of data we may only know at runtime, or we cannot statically represent, so we end up making the systems that consume this configuration data much more complex. (For an example, see Sphinx’s config, I think it does it right).

An example of where I think python-as-configuration has huge power is with complex configuration data like for a plugin system. Instead of relying on some static functionality, the configuration can even be callables that return a plugin instance- so now you don’t have to refer to globals inside of your plugins, you can have your own initializer with a much larger signature, and the plugin system can have its well-defined initialization interface.

I’m not sure I did a great job explaining that example- it deserves its own post. We’ve used it extensively for new tools and systems we’ve developed and it seems to work great (and results in zero globals or singletons used by the plugins, which is an artifact of most plugin systems I’ve seen).

These are my opinions and practices and I know there are plenty good modules which rely on ini/xml/config files. Other than legacy decisions or to be compatible with pre-existing systems, why would someone choose a config file/format over 1) serialized python objects and/or 2) python code?

Published at DZone with permission of Rob Galanakis, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Sc_wizard29 Foo replied on Sun, 2012/07/01 - 5:20pm

Let me tell you why people still use .ini (key=value) files:

  1. Because the "key=value" format is the oldest configuration format in the world, and is easy to parse in any programming language.
  2. Because this format is well understood and relatively easy to modify by non experts.

For #2, I once wrote a piece of software that used an XML configuration file. The lead tester asked me to switch to an .ini file format because the testers needed to modify the configuration file and this was the only format they all understood.

 Now if your "python module" looks like an .ini file, then... there is no problem !

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.