[Python-Dev] ConfigParser shootout, preliminary entry

[Tim Daneliuk]

Bengt Richter wrote:

> On Mon, 18 Oct 2004 17:51:58 -0200, Carlos Ribeiro <carribeiro at gmail.com> wrote:
> 
> 
>>On Mon, 18 Oct 2004 12:20:46 -0700, Josiah Carlson <jcarlson at uci.edu> wrote:
>>
>>>>>I think the syntax looks good, but as per a thread in python-list, you
>>>>>cannot discover the order of class variables by any solution (metaclass
>>>>>or otherwise), due to the fact that they become part of the class
>>>>>dictionary; which is arbitrarily unordered.
>>>>>
>>>>>If ordering is important to a user, one could have an optional
>>>>>__order__
>>>>>attribute that gives the list of items in-order.
>>>>
>>>>That's not quite true.  TypedAttribute instances and iniSection's
>>>>__new__ could have serial numbers.
>>
>>TypedAttributes store their own sequence numbers using a simple
>>counter. Bengt Richter also came up with a clever trick to retrieve a
>>list from the code object itself (using the inspect module and the
>>co_names member). It's very powerful, but it can't check all
>>situations, but I'm sure that it would work for most real world
>>situations.
>>
>>As far as INI files are concerned, order is good but not essential. It
>>helps people that are going to read, or manually edit the config file,
>>and avoids some surprised such as in "what has happened here?" when
>>things seems to appear "out of order".
>>
> 
> Has anyone discussed using the csv module as the basic file interface for config data?
> 
> Windows sort of migrated away from actual .INI files to using the registry, and a
> registry entry with the name of a real ini file can divert apparent operations on
> the file to operations on the registry (for windows apps using the windows API).
> 
> Order does matter in M$ view of INI files. IOW you _can_ (advisability of using ini
> sections that way in another thing ;-) retrieve multiple sym value info from a section
> such as
> 
> [section]
> sym=value1
> sym=value2
> 
> Basic usage is simple and ok, but a clean general info repository it is not, IMO.
> The win32 API for reading and writing INI files is the family of "profile string"
> operations, i.e., this gives an idea of what you are dealing with:

At the risk of sounding like I'm flogging my own software (I am ;), I'd
encourage people to take another look at my 'tconfpy' package:

      https://www.tundraware.com/Software/tconfpy/

It has a number of the features people want already implemented and in-place
including:

- Type AND Value enforcement.  You can insist that a value be integer and
   either within a specified range or one of a list of values.  Strings
   can be limited in length, and so forth.  The documentation only describes
   this for int, string, floating, and complex numbers, but type checking
   should work for any derived type because the placeholder in the symbol
   table just looks for an entry of 'type' - at least I think this is so,
   I've not actually checked it myself.

- Order is made immaterial (up to a point) because [something] introduces
   a *namespace*.  So:

      x=1 # Config var 'x' is set to 1

     [FOO]
     x=1 # Config var 'FOO.x' is set to 1

- The ability to define config vars as ReadOnly

- The ability to "prime" the symbol table before calling the config parser
   so that things are initialized in a way that guarantees sanity from the POV
   of the calling program.

- Conditionals and Directives that allow large, complex configs to be
   decomposed into smaller, more reusable pieces.  This is really useful.
   You can define a systemwide 'standard' configuration that an app reads
   in at startup.  Then it can look for a local configuration (either
   with a second parser call or having the local config ".include" the
   master copy first).  Variables are processed on a 'last one wins'
   basis unless it is declared to be ReadOnly, so the user can override
   any default values in their own config as permitted by the application.

- The ability to escape the parser so that arbitrary literal text can appear
   in a config file where appropriate.

- Local variables with string substitution throughout the config

- The ability to 'template' config variables.  Say, for whatever reason,
   you have a bunch of config information wherein there needs to be an entry
   for each user, but the variable names are the same in each case.  You can
   predefine a template for each common variable that will be used to enforce
   type and value each time that variable shows up in a different context:

     [USER1]
     Name = ...
     EmployeeID = ...

     [USER2]
     Name = ...
     EmployeeID = ...

    You merely define templates for 'Name' and 'EmployeeID' and they are
    applied when the config parser starts to process the USER1 and USER2
    stanzas.  In effect, this extends the configuration engine in a way
    that allows complex, data-centric configurations to be built with type/
    value enforcement.

There are a few warts that I wish were different, but it does work pretty
well and is here now.  At the moment, the license differentiates between
commercial and non-commercial use of the package, so I don't know how that
plays in the Python view of things ...

You can see a toy example at:

     https://www.tundraware.com/Software/tconfpy/example.cfg





----------------------------------------------------------------------------
Tim Daneliuk     tundra at tundraware.com
PGP Key:         http://www.tundraware.com/PGP/