I don’t see anything wrong with that approach. It’s very convenient in languages like Javascript, PHP, etc., and likely speeds things up by removing the need to parse & load configuration values.

Whether its the way to go is a different question. In software that is expected to be configured by a programmer – basically software where the ‘end user’ is a programmer, such as a CMS that gets installed onto a server, it’d work fine. In software that expects a non-technical end user to make configuration changes… probably not a good idea. For example, desktop apps written in Python.

This is exactly how it’s done in Django.

One advantage over e.g. INI files is that you leverage all the power and expressiveness of your language in the configuration, allowing settings to be programmatically generated, and tricks like making the configuration dependent on where the application is running.

However, this power comes at a cost. It prevents you from safely offering any method other than the config file for altering settings (for instance via an “Options” dialog), unless:

1. Your application can decipher the meaning of arbitrary code (which I think is impossible, though I’m not enough of a theorist to be sure about that), or

2. You have an alternative method of storing configuration options set from within the application (and then you have to decide which of those takes precedence in the event of a conflict).

If you are comfortable offering a config file as the only way of configuring your application, however, that suggests you consider your users competent to edit a file containing a simple list of key/value pairs. It follows that there’s no reason they’d be less able to manage that with e.g. Python assignments than with files in INI format, and at the same time you’re able to offer expert users much more powerful configuration techniques.