Allow updates by using .update() like on a dict

[Rijgersberg]

I have remembered approximately one thing from the documenation

a Configuration object is like a dict, but better

Unfortunately, if you try to update one like a dict you get a rather cryptic error.

>>> app_defaults = {'foo': {'bar': 42},
                    'foo.baz': '21 is only half the answer'}
>>> configuration = confidence.Configuration(app_defaults)
>>> configuration.update({'foo': 'qux'})
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: 'NotConfigured' object is not callable

So here's my request: support for dict-like updating of Configuration objects.

[akaIDIOT]

That error is caused by update not being defined for Configuration, at which point it returns the configured value for the key "update", or NotConfigured if that's not available. With the latter being the case, calling that as a function obviously fails.

The rest of the story is a bit of a long one, grab yourself a cappucino :)

TL;DR: change non-trivial, effects finicky, use case peculiar, please elaborate :)

---

As far as remembering things from the documentation (wel... the readme) goes, that's a good one to keep at the back of you mind for sure. The mutability of a Configuration object is where that line isn't fully true though, as you've found out the hard way. The typing of Configuration doesn't state to be a MutableMapping, so not too many lies there, either. The reason for it not being enabled (and in some places even explicitly disabled) are multiple though, so allow me to dive into this a bit here (if only for future reference :P), even though those reasons don't necessarily mean confidence can never support something like this.

First reason is a more philosophical one: the use case for changing configuration values from code at runtime. As long as confidence is being used to create a set of configuration values for a piece of software, changing the configuration at a later point in time is curious; what made the application want to change the configuration it was started with? I think it's mostly analogous to command line arguments (arguable a form of configuration), it'd be odd to change the values on, say, an argparse.Namespace object after the command line arguments were parsed. As a Configuration object is like™ dict, confidence sort of support doing this by creating a new Configuration object from an existing one. This will serve the purpose you might be referring to fine, as long as you're in control of the assignment of the global-like 'configuration variable'. Bar that, confidence has no business telling you how to do your job, so maybe it should adhere to PEP-20 and find a (different?) balance between "Special cases aren't special enough to break the rules" and "Although practicality beats purity".

The second reason stems from the differences in passing things around as either references or values. Due to "Namespaces are one honking great idea -- let's do more of those!", the combination of confidence' attribute namespaces and dict-like behaviour, there's multiple ways of providing a function with configured values:

# option one: use the Configuration object as a first-class citizen (or at least expect some kind of namespace)
def connect_database(db_config):
    ...
db = connect_database(config.database)

# option two: define things with regular arguments and pass those arguments verbatim from configuration
def connect_database(host, port, username, password):
    ...
db = connect_database(**config.database)

confidence has no right to tell you which one to use, but there's a nasty difference between the two if the config object in the example above would be mutable. Depending on how the argument in the first option is used and potentially reused by connect_database, changes to the 'global' config object would be reflected in the config.database namespace; it's passed as a reference to that function (and confidence uses references to the underlying source dicts internally). Using the second option, though, the config.database namespace is 'unpacked' into separate items and passed by value. Should the underlying settings change and connect_database reuse the values at some point (maybe to automatically reconnect a lost connection, for example), it would be none the wiser; the values are still just the values (though the astute reader might notice that this will react like option one for nested namespaces, but that's not the point here). This difference in behaviour is detrimental to the principle of least astonishment, in my mind at least.

Lastly, NotConfigured would need to change quite a bit / be replaced by a magic auto-namespace. Can't see whether that's a value that anyone actually uses, but it would constitute a breaking change (we're pre-1.0 though, so #shrug O:)).

Given all of the above, we could of course still decide this is needed and find neat ways around the stated issues. An implementation of this would at least the following:

• dropping the current state of NotConfigured;
• make a non-root Configuration aware of its place in the namespace hierarchy (currently only tracking a reference to the root);
• decide which of the patterns to change the content of a dict to support:
  • an update()-method (are setdefault(), pop(), ... in scope?);
  • config['namespace.key'] = 42, aka __setitem__;
  • config.namespace.key = 42, aka __setattr__ (coincidentally the one that is currently explicitly implemented to raise an error);
  • some update() library function that gets the Configuration object to be changed as a parameter.

I'm personally leaning towards the "Special cases aren't special enough to break the rules"-side of this, but like confidence, I have little right to tell you how to do your work, so maybe your case is special enough, feel free to convince me ;) Any other users are welcome to chip in btw, don't mean to make this dictatorial ruling :)