/brz/remove-bazaar

==================================

 Reading and Writing Config Files

==================================

----------------------------------------

 ConfigObj 4 Introduction and Reference

----------------------------------------

:Authors: Michael Foord, Nicola Larosa

:Version: ConfigObj 4.4.0

:Date: 2007/02/04

:Homepage: `ConfigObj Homepage`_

:Sourceforge: Sourceforge_

:Development: `SVN Repository`_

:License: `BSD License`_

:Support: `Mailing List`_

.. _Mailing List: http://lists.sourceforge.net/lists/listinfo/configobj-develop

.. _SVN Repository: http://svn.pythonutils.python-hosting.com

.. meta::

   :description: ConfigObj - a Python module for easy reading and writing of 

                 config files.

   :keywords: python, script, module, config, configuration, data, persistence,

              developer, configparser

.. contents:: ConfigObj Manual

.. sectnum::

Introduction

============

**ConfigObj** is a simple but powerful config file reader and writer: an *ini

file round tripper*. Its main feature is that it is very easy to use, with a

straightforward programmer's interface and a simple syntax for config files.

It has lots of other features though :

* Nested sections (subsections), to any level

* List values

* Multiple line values

* String interpolation (substitution)

* Integrated with a powerful validation system

    - including automatic type checking/conversion

    - repeated sections

    - and allowing default values

* All comments in the file are preserved

* The order of keys/sections is preserved

* No external dependencies

* Full Unicode support

* A powerful ``unrepr`` mode for storing basic datatypes

ConfigObj has a barrage of doctests [#]_ built into it, testing almost every

feature. Run ``python configobj_test.py -v`` to see them in action.

For support and bug reports please use the ConfigObj `Mailing List`_.

.. _ConfigObj for Data Persistence: http://www.voidspace.org.uk/python/articles/configobj_for_data_persistence.shtml

.. _ConfigPersist.py: http://www.voidspace.org.uk/python/configpersist.html

Downloading

===========

The current version is **4.4.0**, dated 4th February 2007. ConfigObj 4 is

now stable. We still expect to pick up a few bugs along the way though [#]_.

{sm;:-)}

You can get ConfigObj in the following ways :

Files

-----

* configobj.py_ from Voidspace

    ConfigObj has no external dependencies. This file is sufficient to access

    all the functionality except Validation_.

* configobj.zip_ from Voidspace

    This also contains validate.py_ , the `API Docs`_ and `this document`_.

* The latest development version can be obtained from the `Subversion

  Repository`_.

* validate.py_ from Voidspace

* You can also download *configobj.zip* from Sourceforge_

Documentation

-------------

*configobj.zip* contains `this document`_ and full `API Docs`_, generated by

the EpyDoc_ program.

* You can view `this document`_ online as the `ConfigObj Homepage`_.

* You can also browse the `API Docs`_ online.

Pythonutils

-----------

ConfigObj is also part of the Pythonutils_ set of modules. This contains

various other useful modules, and is required by many of the `Voidspace Python

Projects`_.

Development Version

-------------------

It is sometimes possible to get the latest *development version* of ConfigObj

from the `Subversion Repository <http://svn.pythonutils.python-hosting.com/trunk/pythonutils/>`_.

.. _configobj.py: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj.py

.. _configobj.zip: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj-4.4.0.zip

.. _validate.py: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=validate.py

.. _API Docs: http://www.voidspace.org.uk/python/configobj-api/

.. _this document:

.. _configobj homepage: http://www.voidspace.org.uk/python/configobj.html

.. _Sourceforge: http://sourceforge.net/projects/configobj

.. _EpyDoc: http://epydoc.sourceforge.net

.. _pythonutils: http://www.voidspace.org.uk/python/pythonutils.html

.. _Voidspace Python Projects: http://www.voidspace.org.uk/python

ConfigObj in the Real World

===========================

Projects that use **ConfigObj** include :

* `Bazaar <http://bazaar-ng.org>`_.

    Bazaar is a Python distributed {acro;VCS;Version Control System}.

    ConfigObj is used to read ``bazaar.conf`` and ``branches.conf``.

* `Turbogears <http://www.turbogears.org/>`_

    Turbogears is a web application framework.

* `Chandler <http://chandler.osafoundation.org/>`_

   A Python and `wxPython <http://www.wxpython.org>`_ 

   {acro;PIM;Personal Information Manager}, being developed by the 

   `OSAFoundation <http://www.osafoundation.org/>`_.

* `CryptoBox <https://systemausfall.org/trac/cryptobox/wiki/CryptoBox/en>`_

   A very interesting looking Debian based Live-CD which supports storing 

   data using an encrypted harddisk; usable even by non technical users.

* `Simple64 <http://ubuntuforums.org/showthread.php?t=266290>`_

    A Ubuntu tool which provides a GUI to install a host of applications.

* `Debian-cd-ng <http://wiki.debian.org/debian-cd-ng>`_

    *Debian-cd-ng* recommends ConfigObj for parsing the Debian-cd configuration files.

* `NeuroImaging in Python <http://projects.scipy.org/neuroimaging/ni/wiki>`_

    BrainSTAT is a project with the ultimate goal to produce a

    platform-independent python environment for the analysis of brain

    imaging data.

* `Gruik <http://www.tracos.org/gruik/wiki>`_

    Gruik is a free software network packet sniffer.

Getting Started

===============

The outstanding feature of using ConfigObj is simplicity. Most functions can be

performed with single line commands.

Reading a Config File

---------------------

The normal way to read a config file, is to give ConfigObj the filename :

.. raw:: html

    {+coloring}

    from configobj import ConfigObj

    config = ConfigObj(filename)

    {-coloring}

You can also pass the config file in as a list of lines, or a ``StringIO``

instance, so it doesn't matter where your config data comes from.

You can then access members of your config file as a dictionary. Subsections

will also be dictionaries.

.. raw:: html

    {+coloring}

    from configobj import ConfigObj

    config = ConfigObj(filename)

    #

    value1 = config['keyword1']

    value2 = config['keyword2']

    #

    section1 = config['section1']

    value3 = section1['keyword3']

    value4 = section1['keyword4']

    #

    # you could also write

    value3 = config['section1']['keyword3']

    value4 = config['section1']['keyword4']

    {-coloring}

Writing a Config File

---------------------

Creating a new config file is just as easy as reading one. You can specify a

filename when you create the ConfigObj, or do it later [#]_.

If you *don't* set a filename, then the ``write`` method will return a list of

lines instead of writing to file. See the write_ method for more details.

Here we show creating an empty ConfigObj, setting a filename and some values,

and then writing to file :

.. raw:: html

    {+coloring}

    from configobj import ConfigObj

    config = ConfigObj()

    config.filename = filename

    #

    config['keyword1'] = value1

    config['keyword2'] = value2

    #

    config['section1'] = {}

    config['section1']['keyword3'] = value3

    config['section1']['keyword4'] = value4

    #

    section2 = {

        'keyword5': value5,

        'keyword6': value6,

        'sub-section': {

            'keyword7': value7

            }

    }

    config['section2'] = section2

    #

    config['section3'] = {}

    config['section3']['keyword 8'] = [value8, value9, value10]

    config['section3']['keyword 9'] = [value11, value12, value13]

    #

    config.write()

    {-coloring}

.. caution::

    Keywords and section names can only be strings [#]_. Attempting to set

    anything else will raise a ``ValueError``.

Config Files

------------

The config files that ConfigObj will read and write are based on the 'INI'

format. This means it will read and write files created for ``ConfigParser``

[#]_.

Keywords and values are separated by an ``'='``, and section markers are

between square brackets. Keywords, values, and section names can be surrounded

by single or double quotes. Indentation is not significant, but can be

preserved.

Subsections are indicated by repeating the square brackets in the section

marker. You nest levels by using more brackets.

You can have list values by separating items with a comma, and values spanning

multiple lines by using triple quotes (single or double).

For full details on all these see `the config file format`_. Here's an example

to illustrate : ::

    # This is the 'initial_comment'

    # Which may be several lines

    keyword1 = value1

    'keyword 2' = 'value 2'

    [ "section 1" ]

    # This comment goes with keyword 3

    keyword 3 = value 3

    'keyword 4' = value4, value 5, 'value 6'

        [[ sub-section ]]    # an inline comment

        # sub-section is inside "section 1"

        'keyword 5' = 'value 7'

        'keyword 6' = '''A multiline value,

    that spans more than one line :-)

    The line breaks are included in the value.'''

            [[[ sub-sub-section ]]]

            # sub-sub-section is *in* 'sub-section'

            # which is in 'section 1'

            'keyword 7' = 'value 8'

    [section 2]    # an inline comment

    keyword8 = "value 9"

    keyword9 = value10     # an inline comment

    # The 'final_comment'

    # Which also may be several lines

ConfigObj specifications

========================

.. raw:: html

    {+coloring}

    config = ConfigObj(infile=None, options=None, **keywargs)

    {-coloring}

infile

------

You don't need to specify an infile. If you omit it, an empty ConfigObj will be

created. ``infile`` *can* be :

* Nothing. In which case the ``filename`` attribute of your ConfigObj will be

  ``None``. You can set a filename at any time.

* A filename. What happens if the file doesn't already exist is determined by

  the options_ ``file_error`` and ``create_empty``. The filename will be

  preserved as the ``filename`` attribute. This can be changed at any time.

* A list of lines. Any trailing newlines will be removed from the lines. The

  ``filename`` attribute of your ConfigObj will be ``None``.

* A ``StringIO`` instance or file object, or any object with a ``read`` method.

  The ``filename`` attribute of your ConfigObj will be ``None`` [#]_.

* A dictionary. You can initialise a ConfigObj from a dictionary [#]_. The

  ``filename`` attribute of your ConfigObj will be ``None``. All keys must be

  strings. In this case, the order of values and sections is arbitrary.

options

-------

There are various options that control the way ConfigObj behaves. They can be

passed in as a dictionary of options, or as keyword arguments. Explicit keyword

arguments override the dictionary.

All of the options are available as attributes after the config file has been

parsed.

ConfigObj has the following options (with the default values shown) :

* 'raise_errors': ``False``

    When parsing, it is possible that the config file will be badly formed. The

    default is to parse the whole file and raise a single error at the end. You

    can set ``raise_errors = True`` to have errors raised immediately. See the

    exceptions_ section for more details.

    Altering this value after initial parsing has no effect.

* 'list_values': ``True``

    If ``True`` (the default) then list values are possible. If ``False``, the

    values are not parsed for lists.

	If ``list_values = False`` then single line values are not quoted or

	unquoted when reading and writing.

    Changing this value affects whether single line values will be quoted or 

    not when writing.

* 'create_empty': ``False``

    If this value is ``True`` and the file specified by ``infile`` doesn't

    exist, ConfigObj will create an empty file. This can be a useful test that

    the filename makes sense: an impossible filename will cause an error.

    Altering this value after initial parsing has no effect.

* 'file_error': ``False``

    If this value is ``True`` and the file specified by ``infile`` doesn't

    exist, ConfigObj will raise an ``IOError``.

    Altering this value after initial parsing has no effect.

* 'interpolation': ``True``

    Whether string interpolation is switched on or not. It is on (``True``) by

    default.

    You can set this attribute to change whether string interpolation is done

    when values are fetched. See the `String Interpolation`_ section for more details.

* 'configspec': ``None``

    If you want to use the validation system, you supply a configspec. This is

    effectively a type of config file that specifies a check for each member.

    This check can be used to do type conversion as well as check that the

    value is within your required parameters.

    You provide a configspec in the same way as you do the initial file: a

    filename, or list of lines, etc. See the validation_ section for full

    details on how to use the system.

    When parsed, every section has a ``configspec`` with a dictionary of

    configspec checks for *that section*.

* 'stringify': ``True``

    If you use the validation scheme, it can do type checking *and* conversion

    for you. This means you may want to set members to integers, or other

    non-string values.

    If 'stringify' is set to ``True`` (default) then non-string values will

    be converted to strings when you write the config file. The validation_

    process converts values from strings to the required type.

    If 'stringify' is set to ``False``, attempting to set a member to a

    non-string value [#]_ will raise a ``TypeError`` (no type conversion is

    done by validation).

* 'indent_type': ``'    '``

    Indentation is not significant; it can however be present in the input and

    output config. Any combination of tabs and spaces may be used: the string

    will be repeated for each level of indentation. Typical values are: ``''``

    (no indentation), ``'    '`` (indentation with four spaces, the default),

    ``'\t'`` (indentation with one tab).

    If this option is not specified, and the ConfigObj is initialised with a

    dictionary, the indentation used in the output is the default one, that is,

    four spaces.

    If this option is not specified, and the ConfigObj is initialised with a

    list of lines or a file, the indentation used in the first indented line is

    selected and used in all output lines. If no input line is indented, no

    output line will be either.

    If this option *is* specified, the option value is used in the output

    config, overriding the type of indentation in the input config (if any).

* 'encoding': ``None``

    By default **ConfigObj** does not decode the file/strings you pass it into

    Unicode [#]_. If you want your config file as Unicode (keys and members)

    you need to provide an encoding to decode the file with. This encoding will

    also be used to encode the config file when writing.

    You can change the encoding attribute at any time.

    Any characters in your strings that can't be encoded with the specified

    encoding will raise a ``UnicodeEncodeError``.

    .. note::

        ``UTF16`` encoded files will automatically be detected and decoded,

        even if ``encoding`` is ``None``.

        This is because it is a 16-bit encoding, and ConfigObj will mangle it

        (split characters on byte boundaries) if it parses it without decoding.

* 'default_encoding': ``None``

    When using the ``write`` method, **ConfigObj** uses the ``encoding``

    attribute to encode the Unicode strings. If any members (or keys) have

    been set as byte strings instead of Unicode, these must first be decoded

    to Unicode before outputting in the specified encoding.

    ``default_encoding``, if specified, is the encoding used to decode byte

    strings in the **ConfigObj** before writing. If this is ``None``, then

    the Python default encoding (``sys.defaultencoding`` - usually ASCII) is

    used.

    For most Western European users, a value of ``latin-1`` is sensible.

    ``default_encoding`` is *only* used if an ``encoding`` is specified.

    Any characters in byte-strings that can't be decoded using the

    ``default_encoding`` will raise a ``UnicodeDecodeError``.

* 'unrepr': ``False``

    The ``unrepr`` option reads and writes files in a different mode. This

    allows you to store and retrieve the basic Python data-types using config

    files.

    This uses Python syntax for lists and quoting. See `unrepr mode`_ for the

    full details.

* 'write_empty_values': ``False`` 

    If ``write_empty_values`` is ``True``, empty strings are written as

    empty values. See `Empty Values`_ for more details.

Methods

-------

The ConfigObj is a subclass of an object called ``Section``, which is itself a

subclass of ``dict``, the builtin dictionary type. This means it also has

**all** the normal dictionary methods.

In addition, the following `Section Methods`_ may be useful :

* *encode*

* *decode*

* *walk*

* *merge*

* *dict* 

* *as_bool*

* *as_float*

* *as_int*

Read about Sections_ for details of all the methods.

.. hint::

    The *merge* method of sections is a recursive update.

    You can use this to merge sections, or even whole ConfigObjs, into each

    other.

    You would typically use this to create a default ConfigObj and then merge

    in user settings. This way users only need to specify values that are

    different from the default.

The public methods available on ConfigObj are :

* 'write'

* 'validate'

write

~~~~~

::

    write(file_object=None)

This method writes the current ConfigObj and takes a single, optional argument

[#]_.

If you pass in a file like object to the ``write`` method, the config file will

be written to this. (The only method of this object that is used is its

``write`` method, so a ``StringIO`` instance, or any other file like object

will work.)

Otherwise, the behaviour of this method depends on the ``filename`` attribute

of the ConfigObj.

``filename``

    ConfigObj will write the configuration to the file specified.

``None``

    ``write`` returns a list of lines. (Not ``'\n'`` terminated)

First the 'initial_comment' is written, then the config file, followed by the

'final_comment'. Comment lines and inline comments are written with each

key/value.

validate

~~~~~~~~

::

    validate(validator, preserve_errors=False, copy=False)

.. raw:: html

    {+coloring}

    # filename is the config file

    # filename2 is the configspec

    # (which could also be hardcoded into your program)

    config = ConfigObj(filename, configspec=filename2)

    #

    from validate import Validator

    val = Validator()

    test = config.validate(val)

    if test == True:

        print 'Succeeded.'

    {-coloring}

The validate method uses the `validate 

<http://www.voidspace.org.uk/python/validate.html>`__ module to do the

validation.

This method validates the ConfigObj against the configspec. By doing type

conversion as well, it can abstract away the config file altogether and present

the config *data* to your application (in the types it expects it to be).

If the ``configspec`` attribute of the ConfigObj is ``None``, it raises a

``ValueError``.

If the stringify_ attribute is set, this process will convert values to the

type defined in the configspec.

The validate method uses checks specified in the configspec and defined in the

``Validator`` object. It is very easy to extend.

The configspec looks like the config file, but instead of the value, you

specify the check (and any default value). See the validation_ section for

details.

.. hint::

    The system of configspecs can seem confusing at first, but is actually

    quite simple and powerful. For a concrete example of how to use it, you may

    find this blog entry helpful :

    `Transforming Values with ConfigObj <http://www.voidspace.org.uk/python/weblog/arch_d7_2006_03_04.shtml#e257>`_.

    There is also a module to assist in auto-generating configspecs called

    ConfigPersist.py_. Its use is explained in `ConfigObj for Data Persistence`_.

The ``copy`` parameter fills in missing values from the configspec (default

values), *without* marking the values as defaults. It also causes comments to

be copied from the configspec into the config file. This allows you to use a

configspec to create default config files. (Normally default values aren't

written out by the ``write`` method.)

As of ConfigObj 4.3.0 you can also pass in a ConfigObj instance as your

configspec. This is especially useful if you need to specify the encoding of

your configspec file. When you read your configspec file, you *must* specify

``list_values=False``.

.. raw:: html

    {+coloring}

    from configobj import ConfigObj

    configspec = ConfigObj(configspecfilename, encoding='UTF8',

        list_values=False)

    config = ConfigObj(filename, configspec=configspec)

    {-coloring}

Return Value

############

By default, the validate method either returns ``True`` (everything passed) 

or a dictionary of ``True``/``False`` representing pass/fail. The dictionary 

follows the structure of the ConfigObj.

If a whole section passes then it is replaced with the value ``True``. If a 

whole section fails, then it is replaced with the value ``False``.

If a value is missing, and there is no default in the check, then the check 

automatically fails.

The ``validate`` method takes an optional keyword argument ``preserve_errors``.

If you set this to ``True``, instead of getting ``False`` for failed checks you

get the actual error object from the **validate** module. This usually contains

useful information about why the check failed.

See the `flatten_errors`_ function for how to turn your results dictionary into

a useful list of error messages.

Even if ``preserve_errors`` is ``True``, missing keys or sections will still be

represented by a ``False`` in the results dictionary.

Mentioning Default Values

#########################

In the check in your configspec, you can specify a default to be used - by 

using the ``default`` keyword. E.g. ::

    key1 = integer(0, 30, default=15)

    key2 = integer(default=15)

    key3 = boolean(default=True)

    key4 = option('Hello', 'Goodbye', 'Not Today', default='Not Today')

If the configspec check supplies a default and the value is missing in the

config, then the default will be set in your ConfigObj. (It is still passed to

the ``Validator`` so that type conversion can be done: this means the default

value must still pass the check.)

ConfigObj keeps a record of which values come from defaults, using the

``defaults`` attribute of sections_. Any key in this list isn't written out by

the ``write`` method. If a key is set from outside (even to the same value)

then it is removed from the ``defaults`` list.

.. note:

    Even if all the keys in a section are in the defaults list, the section

    marker is still written out.

There is additionally a special case default value of ``None``. If you set the

default value to ``None`` and the value is missing, the value will always be

set to ``None``. As the other checks don't return ``None`` (unless you

implement your own that do), you can tell that this value came from a default

value (and was missing from the config file). It allows an easy way of

implementing optional values. Simply check (and ignore) members that are set

to ``None``.

.. note::

    If stringify_ is ``False`` then ``default=None`` returns ``''`` instead of

    ``None``. This is because setting a value to a non-string raises an error

    if stringify is unset.

The default value can be a list. See `List Values`_ for the way to do this.

Writing invalid default values is a *guaranteed* way of confusing your users.

Default values **must** pass the check.

Mentioning Repeated Sections

############################

In the configspec it is possible to cause *every* sub-section in a section to

be validated using the same configspec. You do this with a section in the

configspec  called ``__many__``. Every sub-section in that section has the

``__many__`` configspec applied to it (without you having to explicitly name

them in advance).

If you define a ``__many__`` type section it must the only sub-section in that

section. Having a ``__many__`` *and* other sub-sections defined in the same

section will raise a ``RepeatSectionError``.

Your ``__many__`` section can have nested subsections, which can also include

``__many__`` type sections.

See `Repeated Sections`_ for examples.

Mentioning SimpleVal

####################

If you just want to check if all members are present, then you can use the

``SimpleVal`` object that comes with ConfigObj. It only fails members if they

are missing.

Write a configspec that has all the members you want to check for, but set

every section to ``''``.

.. raw:: html

    {+coloring}

    val = SimpleVal()

    test = config.validate(val)

    if test is True:

        print 'Succeeded.'

    {-coloring}

Mentioning copy Mode

####################

As discussed in `Mentioning Default Values`_, you can use a configspec to

supply default values. These are marked in the ConfigObj instance as defaults,

and *not* written out by the ``write`` mode. This means that your users only

need to supply values that are different from the defaults.

This can be inconvenient if you *do* want to write out the default values,

for example to write out a default config file.

If you set ``copy=True`` when you call validate, then no values are marked as

defaults. In addition, all comments from the configspec are copied into

your ConfigObj instance. You can then call ``write`` to create your config

file.

There is a limitation with this. In order to allow `String Interpolation`_ to work

within configspecs, ``DEFAULT`` sections are not processed by

validation; even in copy mode.

Attributes

----------

A ConfigObj has the following attributes :

* indent_type

* interpolate

* stringify

* BOM

* initial_comment

* final_comment

* list_values

* encoding

* default_encoding

* unrepr

* write_empty_values

.. note::

    This doesn't include *comments*, *inline_comments*, *defaults*, or

    *configspec*. These are actually attributes of Sections_.

It also has the following attributes as a result of parsing. They correspond to

options_ when the ConfigObj was created, but changing them has no effect.

* raise_errors

* create_empty

* file_error

interpolation

~~~~~~~~~~~~~

ConfigObj can perform string interpolation in a *similar* way to

``ConfigParser``. See the `String Interpolation`_ section for full details.

If ``interpolation`` is set to ``False``, then interpolation is *not* done when

you fetch values.

stringify

~~~~~~~~~

If this attribute is set (``True``) then the validate_ method changes the

values in the ConfigObj. These are turned back into strings when write_ is

called.

If stringify is unset (``False``) then attempting to set a value to a non

string (or a list of strings) will raise a ``TypeError``.

BOM

~~~

If the initial config file *started* with the UTF8 Unicode signature (known

slightly incorrectly as the {acro;BOM;Byte Order Mark}), or the UTF16 BOM, then

this attribute is set to ``True``. Otherwise it is ``False``.

If it is set to ``True`` when ``write`` is called then, if ``encoding`` is set

to ``None`` *or* to ``utf_8`` (and variants) a UTF BOM will be written.

For UTF16 encodings, a BOM is *always* written.

initial_comment

~~~~~~~~~~~~~~~

This is a list of lines. If the ConfigObj is created from an existing file, it

will contain any lines of comments before the start of the members.

If you create a new ConfigObj, this will be an empty list.

The write method puts these lines before it starts writing out the members.

final_comment

~~~~~~~~~~~~~

This is a list of lines. If the ConfigObj is created from an existing file, it

will contain any lines of comments after the last member.

If you create a new ConfigObj, this will be an empty list.

The ``write`` method puts these lines after it finishes writing out the

members.

list_values

~~~~~~~~~~~

This attribute is ``True`` or ``False``. If set to ``False`` then values are

not parsed for list values. In addition single line values are not unquoted.

This allows you to do your own parsing of values. It exists primarily to

support the reading of the configspec_ - but has other use cases.

For example you could use the ``LineParser`` from the

`listquote module <http://www.voidspace.org.uk/python/listquote.html#lineparser>`_ 

to read values for nested lists.

Single line values aren't quoted when writing - but multiline values are

handled as normal.

.. caution::

    Because values aren't quoted, leading or trailing whitespace can be

	lost.

    This behaviour was changed in version 4.0.1.

	Prior to this, single line values might have been quoted; even with

	``list_values=False``. This means that files written by **ConfigObj**

	*could* now be incompatible - and need the quotes removing by hand.

encoding

~~~~~~~~

This is the encoding used to encode the output, when you call ``write``. It

must be a valid encoding `recognised by Python <http://docs.python.org/lib/standard-encodings.html>`_.

If this value is ``None`` then no encoding is done when ``write`` is called.

default_encoding

~~~~~~~~~~~~~~~~

If encoding is set, any byte-strings in your ConfigObj instance (keys or

members) will first be decoded to Unicode using the encoding specified by the

``default_encoding`` attribute. This ensures that the output is in the encoding

specified.

If this value is ``None`` then ``sys.defaultencoding`` is used instead.

unrepr

~~~~~~

Another boolean value. If this is set, then ``repr(value)`` is used to write

values. This writes values in a slightly different way to the normal ConfigObj

file syntax.

This preserves basic Python data-types when read back in. See `unrepr mode`_

for more details.

write_empty_values

~~~~~~~~~~~~~~~~~~

Also boolean. If set, values that are an empty string (``''``) are written as

empty values. See `Empty Values`_ for more details.

The Config File Format

======================

You saw an example config file in the `Config Files`_ section. Here is a fuller

specification of the config files used and created by ConfigObj.

The basic pattern for keywords is : ::

    # comment line

    # comment line

    keyword = value # inline comment

Both keyword and value can optionally be surrounded in quotes. The equals sign

is the only valid divider.

Values can have comments on the lines above them, and an inline comment after

them. This, of course, is optional. See the comments_ section for details.

If a keyword or value starts or ends with whitespace, or contains a quote mark

or comma, then it should be surrounded by quotes. Quotes are not necessary if

whitespace is surrounded by non-whitespace.

Values can also be lists. Lists are comma separated. You indicate a single

member list by a trailing comma. An empty list is shown by a single comma : ::

    keyword1 = value1, value2, value3

    keyword2 = value1, # a single member list

    keyword3 = , # an empty list

Values that contain line breaks (multi-line values) can be surrounded by triple

quotes. These can also be used if a value contains both types of quotes. List

members cannot be surrounded by triple quotes : ::

    keyword1 = ''' A multi line value

    on several

    lines'''     # with a comment

    keyword2 = '''I won't be "afraid".'''

    #

    keyword3 = """ A multi line value

    on several

    lines"""     # with a comment

    keyword4 = """I won't be "afraid"."""

.. warning::

    There is no way of safely quoting values that contain both types of triple

    quotes.

A line that starts with a '#', possibly preceded by whitespace, is a comment.

New sections are indicated by a section marker line. That is the section name

in square brackets. Whitespace around the section name is ignored. The name can

be quoted with single or double quotes. The marker can have comments before it

and an inline comment after it : ::

    # The First Section

    [ section name 1 ] # first section

    keyword1 = value1

    # The Second Section

    [ "section name 2" ] # second section

    keyword2 = value2

Any subsections (sections that are *inside* the current section) are

designated by repeating the square brackets before and after the section name.

The number of square brackets represents the nesting level of the sub-section.

Square brackets may be separated by whitespace; such whitespace, however, will

not be present in the output config written by the ``write`` method.

Indentation is not significant, but can be preserved. See the description of

the ``indent_type`` option, in the `ConfigObj specifications`_ chapter, for the

details.

A *NestingError* will be raised if the number of the opening and the closing

brackets in a section marker is not the same, or if a sub-section's nesting

level is greater than the nesting level of it parent plus one.

In the outer section, single values can only appear before any sub-section.

Otherwise they will belong to the sub-section immediately before them. ::

    # initial comment

    keyword1 = value1

    keyword2 = value2

    [section 1]

    keyword1 = value1

    keyword2 = value2

        [[sub-section]]

        # this is in section 1

        keyword1 = value1

        keyword2 = value2

            [[[nested section]]]

            # this is in sub section

            keyword1 = value1

            keyword2 = value2

        [[sub-section2]]

        # this is in section 1 again

        keyword1 = value1

        keyword2 = value2

    [[sub-section3]]

    # this is also in section 1, indentation is misleading here

    keyword1 = value1

    keyword2 = value2

    # final comment

When parsed, the above config file produces the following data structure :

.. raw:: html

    {+coloring}

    ConfigObj({

        'keyword1': 'value1',

        'keyword2': 'value2',

        'section 1': {

            'keyword1': 'value1',

            'keyword2': 'value2',

            'sub-section': {

                'keyword1': 'value1',

                'keyword2': 'value2',

                'nested section': {

                    'keyword1': 'value1',

                    'keyword2': 'value2',

                },

            },

            'sub-section2': {

                'keyword1': 'value1',

                'keyword2': 'value2',

            },

            'sub-section3': {

                'keyword1': 'value1',

                'keyword2': 'value2',

            },

        },

    })

    {-coloring}

Sections are ordered: note how the structure of the resulting ConfigObj is in

the same order as the original file.

.. note::

    In ConfigObj 4.3.0 *empty values* became valid syntax. They are read as the

    empty string. There is also an option/attribute (``write_empty_values``) to

    allow the writing of these.

    This is mainly to support 'legacy' config files, written from other

    applications. This is documented under `Empty Values`_.

    `unrepr mode`_ introduces *another* syntax variation, used for storing

    basic Python datatypes in config files. {sm;:-)}

Sections

========

Every section in a ConfigObj has certain properties. The ConfigObj itself also

has these properties, because it too is a section (sometimes called the *root

section*).

``Section`` is a subclass of the standard new-class dictionary, therefore it

has **all** the methods of a normal dictionary. This means you can ``update``

and ``clear`` sections.

.. note::

    You create a new section by assigning a member to be a dictionary.

    The new ``Section`` is created *from* the dictionary, but isn't the same

    thing as the dictionary. (So references to the dictionary you use to create

    the section *aren't* references to the new section).

    Note the following.

    .. raw:: html

        {+coloring}

        config = ConfigObj()

        vals = {'key1': 'value 1', 

                'key2': 'value 2'

               }

        config['vals'] = vals

        config['vals'] == vals

        True

        config['vals'] is vals

        False

        {-coloring}

    If you now change ``vals``, the changes won't be reflected in ``config['vals']``.

A section is ordered, following its ``scalars`` and ``sections``

attributes documented below. This means that the following dictionary

attributes return their results in order.

* '__iter__'

    More commonly known as ``for member in section:``.

* '__repr__' and '__str__'

    Any time you print or display the ConfigObj.

* 'items'

* 'iteritems'

* 'iterkeys'

* 'itervalues'

* 'keys'

* 'popitem'

* 'values'

Section Attributes

------------------

* main

    A reference to the main ConfigObj.

* parent

    A reference to the 'parent' section, the section that this section is a

    member of.

    On the ConfigObj this attribute is a reference to itself. You can use this

    to walk up the sections, stopping when ``section.parent is section``.

* depth

    The nesting level of the current section.

    If you create a new ConfigObj and add sections, 1 will be added to the

    depth level between sections.

* defaults

    This attribute is a list of scalars that came from default values. Values

    that came from defaults aren't written out by the ``write`` method.

    Setting any of these values in the section removes them from the defaults

    list.

* scalars, sections

    These attributes are normal lists, representing the order that members,

    single values and subsections appear in the section. The order will either

    be the order of the original config file, *or* the order that you added

    members.

    The order of members in this lists is the order that ``write`` creates in

    the config file. The ``scalars`` list is output before the ``sections``

    list.

    Adding or removing members also alters these lists. You can manipulate the

    lists directly to alter the order of members.

    .. warning::

        If you alter the ``scalars``, ``sections``, or ``defaults`` attributes

        so that they no longer reflect the contents of the section, you will

        break your ConfigObj.

    See also the ``rename`` method.

* comments

    This is a dictionary of comments associated with each member. Each entry is

    a list of lines. These lines are written out before the member.

* inline_comments

    This is *another* dictionary of comments associated with each member. Each

    entry is a string that is put inline with the member.

* configspec

    The configspec attribute is a dictionary mapping scalars to *checks*. A

    check defines the expected type and possibly the allowed values for a

    member.

    The configspec has the same format as a config file, but instead of values

    it has a specification for the value (which may include a default value).

    The validate_ method uses it to check the config file makes sense. If a

    configspec is passed in when the ConfigObj is created, then it is parsed

    and broken up to become the ``configspec`` attribute of each section.

    If you didn't pass in a configspec, this attribute will be ``None`` on the

    root section (the main ConfigObj).

    You can set the configspec attribute directly on a section.

    See the validation_ section for full details of how to write configspecs.

Section Methods

---------------

* **dict**

    This method takes no arguments. It returns a deep copy of the section as a

    dictionary. All subsections will also be dictionaries, and list values will

    be copies, rather than references to the original [#]_.

* **rename**

    ``rename(oldkey, newkey)``

    This method renames a key, without affecting its position in the sequence.

    It is mainly implemented for the ``encode`` and ``decode`` methods, which