ConfigParser shootout, preliminary entry

[Michael Chermside]

Istvan comments:
>  > "as long as the components of the path are valid Python identifiers,
>  > there is a more convenient attribute syntax available:"
> 
> This means that some features can only be used if the parameter
> names are valid python identifiers, right? When I put it that way,
> it is a bit less attractive.

I'm afraid that I can't take credit for the idea of using attribute
syntax for accessing config values... it was Guido's suggestion in
the first place. But I'm not interested in an "appeal to authority"
argument here -- I think I can provide a good argument for why the
attribute syntax is a good idea (so long as there is a different
syntax available also for use with possible non-identifiers).

Code that accesses configuration values usually uses a constant for
the "key". In other words, you often look up "config.get('my_app.maxRows')",
but rarely something like "config.get('my_app.%s' % some_var)".
Furthermore, the keys themselves are rarely determined by external
forces... the programmer is usually free to select whatever name she
likes. Because of this, it is (almost always) quite easy to ensure that
only valid identifiers are used. With little downside, the convenience
to the programmer of typing "config.my_app.maxRows" rather than 
"config.values['my_app.maxRows']" or "config.get('my_app.maxRows') is
worth considering.

Of course, there are still a few issues. One is explicitness... it's
unwise to have too much "magic". On the other hand, the more common
something becomes the more it becomes an idiom in its own right, and
having a somewhat "magical" syntax is more acceptable. For instance,
something like "dup_list = a_list[:]" looks like some kind of peculiar
smiley the first time any user sees it, but once you're used to it
you instantly recognize it as the Python idiom for making a copy.
(Although the new idiom: "dup_list = list(a_list)" is probably better.)
Features like logging and configuration which are ubiquitous are good
canidates for "convenience syntax".

And the other issue is that SOMETIMES one DOES use arbitrary strings
within config files. It isn't always a good idea to tell users to enter
something like "my_app.<name-of-the-server>.numConnections", but when
you DO something like this the server could be named "def", or "44832"
or even something truly dangerous like u"xp\u01a9" or "". So there
MUST be some OTHER means of accessing values in addition to the
attribute syntax so that arbitrary values can be passed.

Anyway... I certainly think that the matter is less than clear-cut, but
in my opinion, this is one of those areas where it's worth having a
little well-bounded "magic" to make the code that much more readable.

-- Michael Chermside