Suppose you have two related pieces of configuration in a configuration module config_foo.py:
config.set("a", "biz")
config.set("b", "baz")
and your application module fetches it like
a = pmnc.config_foo.get("a")
b = pmnc.config_foo.get("b")
then it could lead to a failure if the configuration file is changed between the two get's, and a and b remain in an inconsistent state, which has never existed in the configuration. To access such configuration comprised from multiple pieces, you could either put them all under the same key, as in
config.set("a_b", ("biz", "baz"))
...
a, b = pmnc.config_foo.get("a_b")
or use a dotted hierarchial naming for the keys and use one of the configuration file's special methods for accessing them atomically:
config.set("a_b.0.a", "biz")
config.set("a_b.1.b", "baz")
...
assert pmnc.config_foo.enumerate_keys("a_b.") == \
       [ "a_b.0.a", "a_b.1.b" ]
assert pmnc.config_foo.enumerate_values("a_b.") == \
       [ "biz", "baz" ]
assert pmnc.config_foo.enumerate_items("a_b.") == \
       [ ("a_b.0.a", "biz"), ("a_b.1.b", "baz") ]
Notice how the related configuration parameters have identical dotted prefixes but also contain the numbers to force the order among them, without it the results could have been ordered wrong (in aphabetical order).
Finally, the most complex method exposed by a configuration file is get_factory, which is used to extract the entire callable factory from a configuration file:
config.set("stuff", SomeClass)
config.set("stuff.0.1st_arg", "foo")
config.set("stuff.1.2nd_arg", "bar")
config.set("stuff.biz", "baz")
...
f = pmnc.config_foo.get_factory("stuff")
x = f() # is the same as x = SomeClass("foo", "bar", biz = "baz")