[thomk]

Configuration, by definition, modifies the software.

How much it modifies the software is determined by the software author. If there aren't limits imposed in your example (json) you're still going to get unexpected results. You'll have to limit what's accepted.

Also, what if I allow a config.py file then translate that to .json then back to python? That is no better than just allowing the consumption of a python source file and simply ignoring any disallowed code (again, limiting what is accepted).

I know it's vogue to say configuration as code is bad; that simply has not been my experience.

[alanfranz]

I don't know whether it's vogue or not, I think it's just a bad idea, because you can't restrict HOW MUCH is is modifying the software, and then people needs to know the nuisances of your programming language. What if I need some configuration to be user (not admin) configurable? What if I don't want to learn programming language X just to use a software?

> If there aren't limits imposed in your example (json) you're still going to get unexpected results.

It's very unlikely for a JSON string to be parsed as a class, or to execute any code, unless you do eval() or do unsafe deserialization. A Python config could do anything.

> You'll have to limit what's accepted.

This is much, MUCH easier said than done. How would you do that in Python? Google App Engine had a sort of "restricted python" idea, and it was hard to implement AFAIK. Same thing for Zope/Plone (there was some templating with restrictions, don't remember the precise system). Then, you'd need do document such "restricted python".

> Also, what if I allow a config.py file then translate that to .json then back to python?

I suppose the first config.py is under the control of the user, and the second is under control of a software author. This is ok, because the "second python version" can perform validation and object construction.

Python configs can be OK (but can get messy) if the software you're building is mostly internal, and few people modify it and they all know what they're doing. As soon as you've got a large enough team and or userbase, IMHO executable configurations are painful.

[thomk]

I appreciate the thoughtful response and I respectfully disagree.

I agree with your point about non-technical users, I addressed that in the top level comment on this thread.

Limiting what is accepted isn't hard at all, here's how you do it:

In your config.py module, have a Config class that subclasses a superclass named, say, ConfigBase. ConfigBase implements __init_subclass__ and in there, you can dictate how a subclass is configured and raise descriptive errors if your rules are not followed. You can do the same thing with a metaclass.

With this approach the class does not have to be mainline executable. You can pluck out what you need and use those plucked items however you see fit.

You are essentially consuming a python script as a config file and not actually running it.