The previous section discussed eval(); the same considerations also apply to exec().

Generally, the set of available globals() is tightly controlled. Access to the os and subprocess modules, or the __import__() function, can be eliminated by removing them from the globals provided to exec().

If you have an evil programmer who will cleverly corrupt the configuration files, then recall that they have complete access to the entire Python source. So, why would they waste time cleverly tweaking configuration files when they can just change the application code itself?

One question can be summarized like this: What if someone thinks they can monkey patch the application by forcing new code in via the configuration file? The person trying this is just as likely to break the application through a number of other equally clever or deranged channels. Avoiding Python configuration files won't stop the unscrupulous programmer from breaking things by doing something else that's ill-advised. The Python source is directly available for modification, so unnecessarily worrying about exec() may not be beneficial.

In some cases, it may be necessary to change the philosophy. An application that's highly customizable might actually be a general framework, not a tidy, finished application. A framework is designed to be extended with additional code.

In the case where configuration parameters are downloaded through a web application, then exec(), eval(), and Python syntax should not be used. For these cases, the parameters need to be in a language such as JSON or YAML. Accepting a configuration file from a remote computer is a type of RESTful state transfer. This is covered in Chapter 13, Transmitting and Sharing Objects.

In the next section, we'll explore one of the collections as a way to provide override values and default values in a single, convenient object.