Like most of the Pythomnic application modules, configuration modules are reloadable (what good would they do otherwise ?), hence in your application module two consecutive accesses could fetch different values:

a1 = pmnc.config_foo.get("a")
# suppose config_foo.py is modified and saved at this moment
a2 = pmnc.config_foo.get("a")

To complicate matters, consider the following loop:

sum = 0
for i in range(10):
    sum += pmnc.config_foo.get("a")

If the configuration file is modified between iterations, the entire loop may be compromised. You could write it this way:

sum = 0
a = pmnc.config_foo.get("a")
for i in range(10):
    sum += a

but then the change of the configuration file will not take effect until the entire loop is performed next time. Taking the idea one step further, your code could only consult the configuration once, presumably at cage startup or module reload:

...
sum = 0
for i in range(10):
    sum += a
...
def pmnc_init(...):
    global a
    a = pmnc.config_foo.get("a")

Then, no matter if you have a parameter in a configuration file, even if you change its value, it doesn't take effect until the cage is restarted. This is clearly a different behaviour from the example with which we have started. This difference will concern mostly the person maintaining the cage but not being the original developer, as he or she would have no idea whether a change in configuration has an immediate effect or not.

To simplify maintenance, there are two otherwise identical methods - config_dynamic and config_static in each configuration file. By convention you should put configuration parameters whose change takes effect immediately in config_dynamic, whereas parameters whose change requires a cage restart should be put to config_static.