Thread: [Configobj-develop] ConfigObj Changes

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hello all,

I'm working on some changes to ConfigObj that add new functionality.
These add some of the ``get`` type methods from ConfigParser to
ConfigObj, as well as full unicode support.

Both are *relatively* easy and will become ConfigObj 4.2.0. (I may well
do a beta release first.)

There is a question about the method signature for the get methods. The
ConfigParser methods are :

    get( section, option)

    Get an option value for the named section.

    getint( section, option)

    A convenience method which coerces the option in the specified
section to an integer.

    getfloat( section, option)

    A convenience method which coerces the option in the specified
section to a floating point         number.

    getboolean( section, option)

    A convenience method which coerces the option in the specified
section to a Boolean value.         Note that the accepted values for
the option are "1", "yes", "true", and "on", which cause this        
method to return True, and "0", "no", "false", and "off", which cause it
to return False. These         string values are checked in a
case-insensitive manner. Any other value will cause it to raise        
ValueError.

I *won't* implement get because it clashes with a dictionary method. If
I implement the ``ConfigParser`` compatibility layer then that will
change (but be on a subclass).

My intention is to make these methods *section* methods, so they are
available on all subsections, and to keep the ConfigParser method
signature. For values *not* in a subsection, this leads to the slightly
awkward syntax :

cfg = ConfigObj(cfg_file)
val = cfg.getboolean(None, 'key')

The alternatives are :

* To reverse the order of the arguments, with section defaulting to
None. This leads to confusion in the (theoretical) ConfigParser
compatibility layer, which will of course  be reversed back. It is
*slightly* more friendly for normal use though.

* To make it a method on ConfigObj (*not* sections) and allow section to
be a string *or* a reference to a subsection - in which case the
specified key would be taken from that.

Should I then remove ``istrue`` (added in 4.1.0) which is effectively
the same as ``getboolean`` ? I would deprecate it and add a warning
until 4.3.0.

The unicode changes are reasonably straightforward. I'll re-implement
the system used in ConfigObj 3. (Unless anyone raises any objections or
suggests an alternative).

 You will be able to pass in an (optional)  'encoding' keyword. If
present, this will be used to decode the input. This maps to an
'encoding' attribute which will be used used to encode when writing (and
can obviously be changed).

There will also be a 'default_encoding' keyword/attribute to override
the system default encoding. This is used (to decode) any values that
are byte-strings. These need to be turned into unicode prior to writing
out in the specified output encoding.

If encoding is None (the default) then no encoding or decoding is
explicitly done. This means the default behaviour for ConfigObj is
completely unchanged.

Opinions/responses solicited.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/configobj.html

Thread: [Configobj-develop] ConfigObj Changes

configobj-develop