ConfigParser shootout, preliminary entry

[David Wilson]

Peter Hansen wrote:

> David Wilson wrote:

> Is it enough to say that it is a good idea *for some people*, and
> that you don't need to be convinced that it's a good idea for you,
> or in general, for that to remain a fact?

> And surely you don't really mean that you don't see a relation
> between (key, value) mapping and attributes.  You *can't* mean
> that... they are both forms of associative mapping.  A key or name
> maps to a value.  End of story.  Obvious as all get out.

In the context of the subject, we are discussing here a replacement 
ConfigParser. Any implementation of attribute access would amount to a 
possibly regression in functionality and more incompatibility with how 
Microsoft did it, as keys may be duplicate in .INI land.

My problem is that for some attribute access pattern:

      confobj.<category>.<item>

confobj represents a configuration reader which bears no relation to the 
<category> objects that might be read from a configuration using the 
reader. Furthermore <item> at best would return only the first key 
matching <item> in <category>. At worst it would return a list of all 
matching items which gets points for being extra confusing. We're also 
veering way off normal Python object attribute access semantics.


> Perhaps you meant you don't believe that this obvious relation
> is in itself a good reason to supply both methods of access?
> Or some other point?

It is magic for no reason, and its use is not obvious. 
conf.get_some_item(category = "blah", item = "foo") reads a lot better 
than "conf.blah.foo". My principle objection is that it is magic that 
simply isn't needed, and apart from the simpler syntax, causes more 
complicated code.

Sure, put it in the stdlib. But in 10 years time when every Python 
beginner is using __getattr__ for wholely ungodly uses, don't blame me.

For other configuration systems with different semantics, perhaps a new 
thread should be created. I'm only really here to defend the simplicity 
of the module currently known as 'ConfigParser'.


David.