ConfigParser shootout, preliminary entry

[Peter Hansen]

David Wilson wrote:
> 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?
> 
> 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.

So to recap, even though I might believe it's a good idea
*for me*, in a particular application which I have in mind
and which you know nothing about, you believe that I should
not use such an approach, in my own code, on my own application.
Or at least you would say that I'm committing some sort of
really bad programming mistake by doing so.  Have I got that
right?

Or was it just that *you* don't like this pattern of access
(in which case I'd suggest that you don't have to use it,
since the dictionary approach is provided as well).

> 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.

For me, replace "confobj" with "config", representing the
"configuration information" of the program, and in that case
"category" bears a clear relation to it.  Furthermore, I have
*no duplicate keys*, so I really would like to use the much
simpler form of access "config.logging.maxfilesize" or some
such.

If I had only a "confobj" of your variety, which provided *only*
the dictionary interface, I would be sorely tempted just to read
in all the keys and store them in my own "config" object, which
would then be used as I mentioned above.  I'd really rather not
go to that extra effort.

I think this is a case of you imagining only one style of
access and application, while there are other scenarios where
other forms of access are equally appropriate *or better*.
Nobody is forcing you to use the other method though.

-Peter