[Python-Dev] ConfigParser shootout, preliminary entry

[Carlos Ribeiro]

On Thu, 21 Oct 2004 03:19:35 GMT, Paul McGuire
<ptmcg at austin.rr._bogus_.com> wrote:
> (BTW, my vote is -10 for any config file format that requires definition of
> classes, functions, or other language constructs more complex than
> assignment or arithmetic/string expressions.  Config files should be simple
> text files for easy reading and editing.)

There is a reason why _some_ definition is useful, whatever mechanism
is used to build it. It allows to provide default values, type
information, and also to map internal names to the names used in the
external config file representation. If I understood your idea
correctly, it allows one to read the config data, and parse it
properly; but it has no way to know if a given key received a value of
the correct type, or what to do if a given key was not provided in the
config file. Another issue (as mentioned previously in this thread) is
that sometimes it is desirable to have keys that can't be mapped to
valid Python attribute names (for example, key names with embedded
hyphens).

My own proposal uses a class to build the default representation.
Other people have already posted code that uses classes in different
ways, or that use a conventional Python data structure (for example,
an arrangement of dicts, lists or tuples to define the kays and their
default values). Another possible way is to provide a default text
representation of the INI file as a string; it allows to define which
keys are valid, and to provide default values, but with a very limited
degree of expresiveness. I sincerely think that a class-based
definition is easier to read and to manage than equivalent dict-based
representations or string-based representations.

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com