ConfigParser shootout, preliminary entry
David Wilson
dw at botanicus.net
Sat Oct 23 10:36:02 EDT 2004
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.
More information about the Python-list
mailing list