ConfigParser shootout, preliminary entry

[David Wilson]

Peter Hansen wrote:

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

No.

I'm not sure how you took what I said to mean the above, as I have never 
referred to your style of code or anything else to do with you. To 
reiterate infinitely, I am referring to a configuration file parser. In 
particular, the one present in the standard library which presents an 
interface to Microsoft-style .INI files.

In that parser, __getattr__ cannot be applied cleanly without adding 
nonstandard semantics to the returned attribute - either discard data, 
or return multiple items of a surprising type - a list at best.


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

I am interested only in providing a correct and clean interface to a 
very simple piece of functionality. I am happy to say that anyone that 
uses __getattr__ for .INI files should be shot. If that includes you, it 
would be a sad loss..


  > For me, replace "confobj" with "config", representing the
> "configuration information" of the program, and in that case
> "category" bears a clear relation to it.

NAME
     ConfigParser - Configuration file parser.

The 'config' object you refer to does not appear to be implemented by 
the ConfigParser module.


   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.

Then join the effort to create a new configuration system, *do not* 
pollute ConfigParser. Again I point at the subject line and the footer 
of my previous post.


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

No, I am trying to defend the cleanliness of a very simple class for 
reading a configuration file, not representing configuration data, or 
acting as a mapping or transparent proxy for the items present in a 
configuration.


David.