1
==================================
2
Reading and Writing Config Files
3
==================================
5
----------------------------------------
6
ConfigObj 4 Introduction and Reference
7
----------------------------------------
9
:Authors: Michael Foord, Nicola Larosa
10
:Version: ConfigObj 4.5.1
12
:Homepage: `ConfigObj Homepage`_
13
:Sourceforge: Sourceforge_
14
:Development: `SVN Repository`_
15
:License: `BSD License`_
16
:Support: `Mailing List`_
18
.. _Mailing List: http://lists.sourceforge.net/lists/listinfo/configobj-develop
19
.. _SVN Repository: http://svn.pythonutils.python-hosting.com
22
:description: ConfigObj - a Python module for easy reading and writing of
24
:keywords: python, script, module, config, configuration, data, persistence,
25
developer, configparser
28
.. contents:: ConfigObj Manual
35
**ConfigObj** is a simple but powerful config file reader and writer: an *ini
36
file round tripper*. Its main feature is that it is very easy to use, with a
37
straightforward programmer's interface and a simple syntax for config files.
38
It has lots of other features though :
40
* Nested sections (subsections), to any level
42
* Multiple line values
43
* String interpolation (substitution)
44
* Integrated with a powerful validation system
46
- including automatic type checking/conversion
48
- and allowing default values
50
* All comments in the file are preserved
51
* The order of keys/sections is preserved
52
* No external dependencies
53
* Full Unicode support
54
* A powerful ``unrepr`` mode for storing basic datatypes
57
For support and bug reports please use the ConfigObj `Mailing List`_.
63
The current version is **4.5.1**, dated 5th February 2008. ConfigObj 4 is
64
now stable. We still expect to pick up a few bugs along the way though [#]_.
67
You can get ConfigObj in the following ways :
72
* configobj.py_ from Voidspace
74
ConfigObj has no external dependencies. This file is sufficient to access
75
all the functionality except Validation_.
77
* configobj.zip_ from Voidspace
79
This also contains validate.py_ and `this document`_.
81
* The latest development version can be obtained from the `Subversion
84
* validate.py_ from Voidspace
86
* You can also download *configobj.zip* from Sourceforge_
91
*configobj.zip* also contains `this document`_.
93
* You can view `this document`_ online at the `ConfigObj Homepage`_.
99
ConfigObj is also part of the Pythonutils_ set of modules. This contains
100
various other useful modules, and is required by many of the `Voidspace Python
107
It is sometimes possible to get the latest *development version* of ConfigObj
108
from the `Subversion Repository <http://svn.pythonutils.python-hosting.com/trunk/pythonutils/>`_.
110
.. _configobj.py: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj.py
111
.. _configobj.zip: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj-4.5.1.zip
112
.. _validate.py: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=validate.py
114
.. _configobj homepage: http://www.voidspace.org.uk/python/configobj.html
115
.. _Sourceforge: http://sourceforge.net/projects/configobj
116
.. _pythonutils: http://www.voidspace.org.uk/python/pythonutils.html
117
.. _Voidspace Python Projects: http://www.voidspace.org.uk/python/index.shtml
121
ConfigObj in the Real World
122
===========================
124
**ConfigObj** is widely used. Projects using it include:
126
* `Bazaar <http://bazaar-ng.org>`_.
128
Bazaar is a Python distributed {acro;VCS;Version Control System}.
129
ConfigObj is used to read ``bazaar.conf`` and ``branches.conf``.
131
* `Turbogears <http://www.turbogears.org/>`_
133
Turbogears is a web application framework.
135
* `Chandler <http://chandler.osafoundation.org/>`_
137
A Python and `wxPython <http://www.wxpython.org>`_
138
{acro;PIM;Personal Information Manager}, being developed by the
139
`OSAFoundation <http://www.osafoundation.org/>`_.
141
* `IPython <http://ipython.scipy.org/moin/>`_
143
IPython is an enhanced interactive Python shell. IPython uses ConfigObj in a module called 'TConfig' that combines it with enthought `Traits <http://code.enthought.com/traits/>`_: `tconfig <http://ipython.scipy.org/ipython/ipython/browser/ipython/branches/saw/sandbox/tconfig>`_.
145
* ` Elisa - the Fluendo Mediacenter <http://elisa.fluendo.com/>`_
147
Elisa is an open source cross-platform media center solution designed to be simple for people not particularly familiar with computers.
153
The outstanding feature of using ConfigObj is simplicity. Most functions can be
154
performed with single line commands.
157
Reading a Config File
158
---------------------
160
The normal way to read a config file, is to give ConfigObj the filename :
166
from configobj import ConfigObj
167
config = ConfigObj(filename)
171
You can also pass the config file in as a list of lines, or a ``StringIO``
172
instance, so it doesn't matter where your config data comes from.
174
You can then access members of your config file as a dictionary. Subsections
175
will also be dictionaries.
181
from configobj import ConfigObj
182
config = ConfigObj(filename)
184
value1 = config['keyword1']
185
value2 = config['keyword2']
187
section1 = config['section1']
188
value3 = section1['keyword3']
189
value4 = section1['keyword4']
191
# you could also write
192
value3 = config['section1']['keyword3']
193
value4 = config['section1']['keyword4']
198
Writing a Config File
199
---------------------
201
Creating a new config file is just as easy as reading one. You can specify a
202
filename when you create the ConfigObj, or do it later [#]_.
204
If you *don't* set a filename, then the ``write`` method will return a list of
205
lines instead of writing to file. See the write_ method for more details.
207
Here we show creating an empty ConfigObj, setting a filename and some values,
208
and then writing to file :
214
from configobj import ConfigObj
216
config.filename = filename
218
config['keyword1'] = value1
219
config['keyword2'] = value2
221
config['section1'] = {}
222
config['section1']['keyword3'] = value3
223
config['section1']['keyword4'] = value4
232
config['section2'] = section2
234
config['section3'] = {}
235
config['section3']['keyword 8'] = [value8, value9, value10]
236
config['section3']['keyword 9'] = [value11, value12, value13]
244
Keywords and section names can only be strings [#]_. Attempting to set
245
anything else will raise a ``ValueError``.
251
The config files that ConfigObj will read and write are based on the 'INI'
252
format. This means it will read and write files created for ``ConfigParser``
255
Keywords and values are separated by an ``'='``, and section markers are
256
between square brackets. Keywords, values, and section names can be surrounded
257
by single or double quotes. Indentation is not significant, but can be
260
Subsections are indicated by repeating the square brackets in the section
261
marker. You nest levels by using more brackets.
263
You can have list values by separating items with a comma, and values spanning
264
multiple lines by using triple quotes (single or double).
266
For full details on all these see `the config file format`_. Here's an example
269
# This is the 'initial_comment'
270
# Which may be several lines
272
'keyword 2' = 'value 2'
275
# This comment goes with keyword 3
277
'keyword 4' = value4, value 5, 'value 6'
279
[[ sub-section ]] # an inline comment
280
# sub-section is inside "section 1"
281
'keyword 5' = 'value 7'
282
'keyword 6' = '''A multiline value,
283
that spans more than one line :-)
284
The line breaks are included in the value.'''
286
[[[ sub-sub-section ]]]
287
# sub-sub-section is *in* 'sub-section'
288
# which is in 'section 1'
289
'keyword 7' = 'value 8'
291
[section 2] # an inline comment
293
keyword9 = value10 # an inline comment
294
# The 'final_comment'
295
# Which also may be several lines
298
ConfigObj specifications
299
========================
305
config = ConfigObj(infile=None, options=None, **keywargs)
313
You don't need to specify an infile. If you omit it, an empty ConfigObj will be
314
created. ``infile`` *can* be :
316
* Nothing. In which case the ``filename`` attribute of your ConfigObj will be
317
``None``. You can set a filename at any time.
319
* A filename. What happens if the file doesn't already exist is determined by
320
the options_ ``file_error`` and ``create_empty``. The filename will be
321
preserved as the ``filename`` attribute. This can be changed at any time.
323
* A list of lines. Any trailing newlines will be removed from the lines. The
324
``filename`` attribute of your ConfigObj will be ``None``.
326
* A ``StringIO`` instance or file object, or any object with a ``read`` method.
327
The ``filename`` attribute of your ConfigObj will be ``None`` [#]_.
329
* A dictionary. You can initialise a ConfigObj from a dictionary [#]_. The
330
``filename`` attribute of your ConfigObj will be ``None``. All keys must be
331
strings. In this case, the order of values and sections is arbitrary.
337
There are various options that control the way ConfigObj behaves. They can be
338
passed in as a dictionary of options, or as keyword arguments. Explicit keyword
339
arguments override the dictionary.
341
All of the options are available as attributes after the config file has been
344
ConfigObj has the following options (with the default values shown) :
346
* 'raise_errors': ``False``
348
When parsing, it is possible that the config file will be badly formed. The
349
default is to parse the whole file and raise a single error at the end. You
350
can set ``raise_errors = True`` to have errors raised immediately. See the
351
exceptions_ section for more details.
353
Altering this value after initial parsing has no effect.
355
* 'list_values': ``True``
357
If ``True`` (the default) then list values are possible. If ``False``, the
358
values are not parsed for lists.
360
If ``list_values = False`` then single line values are not quoted or
361
unquoted when reading and writing.
363
Changing this value affects whether single line values will be quoted or
366
* 'create_empty': ``False``
368
If this value is ``True`` and the file specified by ``infile`` doesn't
369
exist, ConfigObj will create an empty file. This can be a useful test that
370
the filename makes sense: an impossible filename will cause an error.
372
Altering this value after initial parsing has no effect.
374
* 'file_error': ``False``
376
If this value is ``True`` and the file specified by ``infile`` doesn't
377
exist, ConfigObj will raise an ``IOError``.
379
Altering this value after initial parsing has no effect.
381
* 'interpolation': ``True``
383
Whether string interpolation is switched on or not. It is on (``True``) by
386
You can set this attribute to change whether string interpolation is done
387
when values are fetched. See the `String Interpolation`_ section for more details.
389
* 'configspec': ``None``
391
If you want to use the validation system, you supply a configspec. This is
392
effectively a type of config file that specifies a check for each member.
393
This check can be used to do type conversion as well as check that the
394
value is within your required parameters.
396
You provide a configspec in the same way as you do the initial file: a
397
filename, or list of lines, etc. See the validation_ section for full
398
details on how to use the system.
400
When parsed, every section has a ``configspec`` with a dictionary of
401
configspec checks for *that section*.
403
* 'stringify': ``True``
405
If you use the validation scheme, it can do type checking *and* conversion
406
for you. This means you may want to set members to integers, or other
409
If 'stringify' is set to ``True`` (default) then non-string values will
410
be converted to strings when you write the config file. The validation_
411
process converts values from strings to the required type.
413
If 'stringify' is set to ``False``, attempting to set a member to a
414
non-string value [#]_ will raise a ``TypeError`` (no type conversion is
417
* 'indent_type': ``' '``
419
Indentation is not significant; it can however be present in the input and
420
output config. Any combination of tabs and spaces may be used: the string
421
will be repeated for each level of indentation. Typical values are: ``''``
422
(no indentation), ``' '`` (indentation with four spaces, the default),
423
``'\t'`` (indentation with one tab).
425
If this option is not specified, and the ConfigObj is initialised with a
426
dictionary, the indentation used in the output is the default one, that is,
429
If this option is not specified, and the ConfigObj is initialised with a
430
list of lines or a file, the indentation used in the first indented line is
431
selected and used in all output lines. If no input line is indented, no
432
output line will be either.
434
If this option *is* specified, the option value is used in the output
435
config, overriding the type of indentation in the input config (if any).
437
* 'encoding': ``None``
439
By default **ConfigObj** does not decode the file/strings you pass it into
440
Unicode [#]_. If you want your config file as Unicode (keys and members)
441
you need to provide an encoding to decode the file with. This encoding will
442
also be used to encode the config file when writing.
444
You can change the encoding attribute at any time.
446
Any characters in your strings that can't be encoded with the specified
447
encoding will raise a ``UnicodeEncodeError``.
451
``UTF16`` encoded files will automatically be detected and decoded,
452
even if ``encoding`` is ``None``.
454
This is because it is a 16-bit encoding, and ConfigObj will mangle it
455
(split characters on byte boundaries) if it parses it without decoding.
457
* 'default_encoding': ``None``
459
When using the ``write`` method, **ConfigObj** uses the ``encoding``
460
attribute to encode the Unicode strings. If any members (or keys) have
461
been set as byte strings instead of Unicode, these must first be decoded
462
to Unicode before outputting in the specified encoding.
464
``default_encoding``, if specified, is the encoding used to decode byte
465
strings in the **ConfigObj** before writing. If this is ``None``, then
466
the Python default encoding (``sys.defaultencoding`` - usually ASCII) is
469
For most Western European users, a value of ``latin-1`` is sensible.
471
``default_encoding`` is *only* used if an ``encoding`` is specified.
473
Any characters in byte-strings that can't be decoded using the
474
``default_encoding`` will raise a ``UnicodeDecodeError``.
476
* 'unrepr': ``False``
478
The ``unrepr`` option reads and writes files in a different mode. This
479
allows you to store and retrieve the basic Python data-types using config
482
This uses Python syntax for lists and quoting. See `unrepr mode`_ for the
485
* 'write_empty_values': ``False``
487
If ``write_empty_values`` is ``True``, empty strings are written as
488
empty values. See `Empty Values`_ for more details.
494
The ConfigObj is a subclass of an object called ``Section``, which is itself a
495
subclass of ``dict``, the builtin dictionary type. This means it also has
496
**all** the normal dictionary methods.
498
In addition, the following `Section Methods`_ may be useful :
509
Read about Sections_ for details of all the methods.
513
The *merge* method of sections is a recursive update.
515
You can use this to merge sections, or even whole ConfigObjs, into each
518
You would typically use this to create a default ConfigObj and then merge
519
in user settings. This way users only need to specify values that are
520
different from the default. You can use configspecs and validation to
521
achieve the same thing of course.
524
The public methods available on ConfigObj are :
537
write(file_object=None)
539
This method writes the current ConfigObj and takes a single, optional argument
542
If you pass in a file like object to the ``write`` method, the config file will
543
be written to this. (The only method of this object that is used is its
544
``write`` method, so a ``StringIO`` instance, or any other file like object
547
Otherwise, the behaviour of this method depends on the ``filename`` attribute
551
ConfigObj will write the configuration to the file specified.
554
``write`` returns a list of lines. (Not ``'\n'`` terminated)
556
First the 'initial_comment' is written, then the config file, followed by the
557
'final_comment'. Comment lines and inline comments are written with each
566
validate(validator, preserve_errors=False, copy=False)
572
# filename is the config file
573
# filename2 is the configspec
574
# (which could also be hardcoded into your program)
575
config = ConfigObj(filename, configspec=filename2)
577
from validate import Validator
579
test = config.validate(val)
584
The validate method uses the `validate
585
<http://www.voidspace.org.uk/python/validate.html>`__ module to do the
588
This method validates the ConfigObj against the configspec. By doing type
589
conversion as well it can abstract away the config file altogether and present
590
the config *data* to your application (in the types it expects it to be).
592
If the ``configspec`` attribute of the ConfigObj is ``None``, it raises a
595
If the stringify_ attribute is set, this process will convert values to the
596
type defined in the configspec.
598
The validate method uses checks specified in the configspec and defined in the
599
``Validator`` object. It is very easy to extend.
601
The configspec looks like the config file, but instead of the value, you
602
specify the check (and any default value). See the validation_ section for
607
The system of configspecs can seem confusing at first, but is actually
608
quite simple and powerful. For a concrete example of how to use it, you may
609
find this blog entry helpful :
610
`Transforming Values with ConfigObj <http://www.voidspace.org.uk/python/weblog/arch_d7_2006_03_04.shtml#e257>`_.
613
The ``copy`` parameter fills in missing values from the configspec (default
614
values), *without* marking the values as defaults. It also causes comments to
615
be copied from the configspec into the config file. This allows you to use a
616
configspec to create default config files. (Normally default values aren't
617
written out by the ``write`` method.)
619
As of ConfigObj 4.3.0 you can also pass in a ConfigObj instance as your
620
configspec. This is especially useful if you need to specify the encoding of
621
your configspec file. When you read your configspec file, you *must* specify
622
``list_values=False``.
627
from configobj import ConfigObj
628
configspec = ConfigObj(configspecfilename, encoding='UTF8',
630
config = ConfigObj(filename, configspec=configspec)
637
By default, the validate method either returns ``True`` (everything passed)
638
or a dictionary of ``True``/``False`` representing pass/fail. The dictionary
639
follows the structure of the ConfigObj.
641
If a whole section passes then it is replaced with the value ``True``. If a
642
whole section fails, then it is replaced with the value ``False``.
644
If a value is missing, and there is no default in the check, then the check
647
The ``validate`` method takes an optional keyword argument ``preserve_errors``.
648
If you set this to ``True``, instead of getting ``False`` for failed checks you
649
get the actual error object from the **validate** module. This usually contains
650
useful information about why the check failed.
652
See the `flatten_errors`_ function for how to turn your results dictionary into
653
a useful list of error messages.
655
Even if ``preserve_errors`` is ``True``, missing keys or sections will still be
656
represented by a ``False`` in the results dictionary.
659
Mentioning Default Values
660
#########################
662
In the check in your configspec, you can specify a default to be used - by
663
using the ``default`` keyword. E.g. ::
665
key1 = integer(0, 30, default=15)
666
key2 = integer(default=15)
667
key3 = boolean(default=True)
668
key4 = option('Hello', 'Goodbye', 'Not Today', default='Not Today')
670
If the configspec check supplies a default and the value is missing in the
671
config, then the default will be set in your ConfigObj. (It is still passed to
672
the ``Validator`` so that type conversion can be done: this means the default
673
value must still pass the check.)
675
ConfigObj keeps a record of which values come from defaults, using the
676
``defaults`` attribute of sections_. Any key in this list isn't written out by
677
the ``write`` method. If a key is set from outside (even to the same value)
678
then it is removed from the ``defaults`` list.
682
Even if all the keys in a section are in the defaults list, the section
683
marker is still written out.
685
There is additionally a special case default value of ``None``. If you set the
686
default value to ``None`` and the value is missing, the value will always be
687
set to ``None``. As the other checks don't return ``None`` (unless you
688
implement your own that do), you can tell that this value came from a default
689
value (and was missing from the config file). It allows an easy way of
690
implementing optional values. Simply check (and ignore) members that are set
695
If stringify_ is ``False`` then ``default=None`` returns ``''`` instead of
696
``None``. This is because setting a value to a non-string raises an error
697
if stringify is unset.
699
The default value can be a list. See `List Values`_ for the way to do this.
701
Writing invalid default values is a *guaranteed* way of confusing your users.
702
Default values **must** pass the check.
705
Mentioning Repeated Sections
706
############################
708
In the configspec it is possible to cause *every* sub-section in a section to
709
be validated using the same configspec. You do this with a section in the
710
configspec called ``__many__``. Every sub-section in that section has the
711
``__many__`` configspec applied to it (without you having to explicitly name
714
If you define a ``__many__`` type section it must the only sub-section in that
715
section. Having a ``__many__`` *and* other sub-sections defined in the same
716
section will raise a ``RepeatSectionError``.
718
Your ``__many__`` section can have nested subsections, which can also include
719
``__many__`` type sections.
721
See `Repeated Sections`_ for examples.
727
If you just want to check if all members are present, then you can use the
728
``SimpleVal`` object that comes with ConfigObj. It only fails members if they
731
Write a configspec that has all the members you want to check for, but set
732
every section to ``''``.
739
test = config.validate(val)
749
As discussed in `Mentioning Default Values`_, you can use a configspec to
750
supply default values. These are marked in the ConfigObj instance as defaults,
751
and *not* written out by the ``write`` mode. This means that your users only
752
need to supply values that are different from the defaults.
754
This can be inconvenient if you *do* want to write out the default values,
755
for example to write out a default config file.
757
If you set ``copy=True`` when you call validate, then no values are marked as
758
defaults. In addition, all comments from the configspec are copied into
759
your ConfigObj instance. You can then call ``write`` to create your config
762
There is a limitation with this. In order to allow `String Interpolation`_ to work
763
within configspecs, ``DEFAULT`` sections are not processed by
764
validation; even in copy mode.
770
If a ConfigObj instance was loaded from the filesystem, then this method will reload it. It
771
will also reuse any configspec you supplied at instantiation (including reloading it from
772
the filesystem if you passed it in as a filename).
774
If the ConfigObj does not have a filename attribute pointing to a file, then a ``ReloadError``
781
This method takes no arguments and doesn't return anything. It restores a ConfigObj
782
instance to a freshly created state.
788
A ConfigObj has the following attributes :
805
This doesn't include *comments*, *inline_comments*, *defaults*, or
806
*configspec*. These are actually attributes of Sections_.
808
It also has the following attributes as a result of parsing. They correspond to
809
options_ when the ConfigObj was created, but changing them has no effect.
819
ConfigObj can perform string interpolation in a *similar* way to
820
``ConfigParser``. See the `String Interpolation`_ section for full details.
822
If ``interpolation`` is set to ``False``, then interpolation is *not* done when
829
If this attribute is set (``True``) then the validate_ method changes the
830
values in the ConfigObj. These are turned back into strings when write_ is
833
If stringify is unset (``False``) then attempting to set a value to a non
834
string (or a list of strings) will raise a ``TypeError``.
840
If the initial config file *started* with the UTF8 Unicode signature (known
841
slightly incorrectly as the {acro;BOM;Byte Order Mark}), or the UTF16 BOM, then
842
this attribute is set to ``True``. Otherwise it is ``False``.
844
If it is set to ``True`` when ``write`` is called then, if ``encoding`` is set
845
to ``None`` *or* to ``utf_8`` (and variants) a UTF BOM will be written.
847
For UTF16 encodings, a BOM is *always* written.
853
This is a list of lines. If the ConfigObj is created from an existing file, it
854
will contain any lines of comments before the start of the members.
856
If you create a new ConfigObj, this will be an empty list.
858
The write method puts these lines before it starts writing out the members.
864
This is a list of lines. If the ConfigObj is created from an existing file, it
865
will contain any lines of comments after the last member.
867
If you create a new ConfigObj, this will be an empty list.
869
The ``write`` method puts these lines after it finishes writing out the
876
This attribute is ``True`` or ``False``. If set to ``False`` then values are
877
not parsed for list values. In addition single line values are not unquoted.
879
This allows you to do your own parsing of values. It exists primarily to
880
support the reading of the configspec_ - but has other use cases.
882
For example you could use the ``LineParser`` from the
883
`listquote module <http://www.voidspace.org.uk/python/listquote.html#lineparser>`_
884
to read values for nested lists.
886
Single line values aren't quoted when writing - but multiline values are
891
Because values aren't quoted, leading or trailing whitespace can be
894
This behaviour was changed in version 4.0.1.
896
Prior to this, single line values might have been quoted; even with
897
``list_values=False``. This means that files written by **ConfigObj**
898
*could* now be incompatible - and need the quotes removing by hand.
904
This is the encoding used to encode the output, when you call ``write``. It
905
must be a valid encoding `recognised by Python <http://docs.python.org/lib/standard-encodings.html>`_.
907
If this value is ``None`` then no encoding is done when ``write`` is called.
913
If encoding is set, any byte-strings in your ConfigObj instance (keys or
914
members) will first be decoded to Unicode using the encoding specified by the
915
``default_encoding`` attribute. This ensures that the output is in the encoding
918
If this value is ``None`` then ``sys.defaultencoding`` is used instead.
924
Another boolean value. If this is set, then ``repr(value)`` is used to write
925
values. This writes values in a slightly different way to the normal ConfigObj
928
This preserves basic Python data-types when read back in. See `unrepr mode`_
935
Also boolean. If set, values that are an empty string (``''``) are written as
936
empty values. See `Empty Values`_ for more details.
942
When a config file is read, ConfigObj records the type of newline separators in the
943
file and uses this separator when writing. It defaults to ``None``, and ConfigObj
944
uses the system default (``os.sep``) if write is called without newlines having
948
The Config File Format
949
======================
951
You saw an example config file in the `Config Files`_ section. Here is a fuller
952
specification of the config files used and created by ConfigObj.
954
The basic pattern for keywords is : ::
958
keyword = value # inline comment
960
Both keyword and value can optionally be surrounded in quotes. The equals sign
961
is the only valid divider.
963
Values can have comments on the lines above them, and an inline comment after
964
them. This, of course, is optional. See the comments_ section for details.
966
If a keyword or value starts or ends with whitespace, or contains a quote mark
967
or comma, then it should be surrounded by quotes. Quotes are not necessary if
968
whitespace is surrounded by non-whitespace.
970
Values can also be lists. Lists are comma separated. You indicate a single
971
member list by a trailing comma. An empty list is shown by a single comma : ::
973
keyword1 = value1, value2, value3
974
keyword2 = value1, # a single member list
975
keyword3 = , # an empty list
977
Values that contain line breaks (multi-line values) can be surrounded by triple
978
quotes. These can also be used if a value contains both types of quotes. List
979
members cannot be surrounded by triple quotes : ::
981
keyword1 = ''' A multi line value
983
lines''' # with a comment
984
keyword2 = '''I won't be "afraid".'''
986
keyword3 = """ A multi line value
988
lines""" # with a comment
989
keyword4 = """I won't be "afraid"."""
993
There is no way of safely quoting values that contain both types of triple
996
A line that starts with a '#', possibly preceded by whitespace, is a comment.
998
New sections are indicated by a section marker line. That is the section name
999
in square brackets. Whitespace around the section name is ignored. The name can
1000
be quoted with single or double quotes. The marker can have comments before it
1001
and an inline comment after it : ::
1004
[ section name 1 ] # first section
1007
# The Second Section
1008
[ "section name 2" ] # second section
1011
Any subsections (sections that are *inside* the current section) are
1012
designated by repeating the square brackets before and after the section name.
1013
The number of square brackets represents the nesting level of the sub-section.
1014
Square brackets may be separated by whitespace; such whitespace, however, will
1015
not be present in the output config written by the ``write`` method.
1017
Indentation is not significant, but can be preserved. See the description of
1018
the ``indent_type`` option, in the `ConfigObj specifications`_ chapter, for the
1021
A *NestingError* will be raised if the number of the opening and the closing
1022
brackets in a section marker is not the same, or if a sub-section's nesting
1023
level is greater than the nesting level of it parent plus one.
1025
In the outer section, single values can only appear before any sub-section.
1026
Otherwise they will belong to the sub-section immediately before them. ::
1037
# this is in section 1
1041
[[[nested section]]]
1042
# this is in sub section
1047
# this is in section 1 again
1052
# this is also in section 1, indentation is misleading here
1058
When parsed, the above config file produces the following data structure :
1065
'keyword1': 'value1',
1066
'keyword2': 'value2',
1068
'keyword1': 'value1',
1069
'keyword2': 'value2',
1071
'keyword1': 'value1',
1072
'keyword2': 'value2',
1074
'keyword1': 'value1',
1075
'keyword2': 'value2',
1079
'keyword1': 'value1',
1080
'keyword2': 'value2',
1083
'keyword1': 'value1',
1084
'keyword2': 'value2',
1091
Sections are ordered: note how the structure of the resulting ConfigObj is in
1092
the same order as the original file.
1096
In ConfigObj 4.3.0 *empty values* became valid syntax. They are read as the
1097
empty string. There is also an option/attribute (``write_empty_values``) to
1098
allow the writing of these.
1100
This is mainly to support 'legacy' config files, written from other
1101
applications. This is documented under `Empty Values`_.
1103
`unrepr mode`_ introduces *another* syntax variation, used for storing
1104
basic Python datatypes in config files. {sm;:-)}
1110
Every section in a ConfigObj has certain properties. The ConfigObj itself also
1111
has these properties, because it too is a section (sometimes called the *root
1114
``Section`` is a subclass of the standard new-class dictionary, therefore it
1115
has **all** the methods of a normal dictionary. This means you can ``update``
1116
and ``clear`` sections.
1120
You create a new section by assigning a member to be a dictionary.
1122
The new ``Section`` is created *from* the dictionary, but isn't the same
1123
thing as the dictionary. (So references to the dictionary you use to create
1124
the section *aren't* references to the new section).
1132
config = ConfigObj()
1133
vals = {'key1': 'value 1',
1136
config['vals'] = vals
1137
config['vals'] == vals
1139
config['vals'] is vals
1144
If you now change ``vals``, the changes won't be reflected in ``config['vals']``.
1146
A section is ordered, following its ``scalars`` and ``sections``
1147
attributes documented below. This means that the following dictionary
1148
attributes return their results in order.
1152
More commonly known as ``for member in section:``.
1154
* '__repr__' and '__str__'
1156
Any time you print or display the ConfigObj.
1178
A reference to the main ConfigObj.
1182
A reference to the 'parent' section, the section that this section is a
1185
On the ConfigObj this attribute is a reference to itself. You can use this
1186
to walk up the sections, stopping when ``section.parent is section``.
1190
The nesting level of the current section.
1192
If you create a new ConfigObj and add sections, 1 will be added to the
1193
depth level between sections.
1197
This attribute is a list of scalars that came from default values. Values
1198
that came from defaults aren't written out by the ``write`` method.
1199
Setting any of these values in the section removes them from the defaults
1204
This attribute is a dictionary mapping keys to the default values for the
1205
keys. By default it is an empty dictionary and is populated when you
1206
validate the ConfigObj.
1210
These attributes are normal lists, representing the order that members,
1211
single values and subsections appear in the section. The order will either
1212
be the order of the original config file, *or* the order that you added
1215
The order of members in this lists is the order that ``write`` creates in
1216
the config file. The ``scalars`` list is output before the ``sections``
1219
Adding or removing members also alters these lists. You can manipulate the
1220
lists directly to alter the order of members.
1224
If you alter the ``scalars``, ``sections``, or ``defaults`` attributes
1225
so that they no longer reflect the contents of the section, you will
1226
break your ConfigObj.
1228
See also the ``rename`` method.
1232
This is a dictionary of comments associated with each member. Each entry is
1233
a list of lines. These lines are written out before the member.
1237
This is *another* dictionary of comments associated with each member. Each
1238
entry is a string that is put inline with the member.
1242
The configspec attribute is a dictionary mapping scalars to *checks*. A
1243
check defines the expected type and possibly the allowed values for a
1246
The configspec has the same format as a config file, but instead of values
1247
it has a specification for the value (which may include a default value).
1248
The validate_ method uses it to check the config file makes sense. If a
1249
configspec is passed in when the ConfigObj is created, then it is parsed
1250
and broken up to become the ``configspec`` attribute of each section.
1252
If you didn't pass in a configspec, this attribute will be ``None`` on the
1253
root section (the main ConfigObj).
1255
You can set the configspec attribute directly on a section.
1257
See the validation_ section for full details of how to write configspecs.
1265
This method takes no arguments. It returns a deep copy of the section as a
1266
dictionary. All subsections will also be dictionaries, and list values will
1267
be copies, rather than references to the original [#]_.
1271
``rename(oldkey, newkey)``
1273
This method renames a key, without affecting its position in the sequence.
1275
It is mainly implemented for the ``encode`` and ``decode`` methods, which
1276
provide some Unicode support.
1282
This method is a *recursive update* method. It allows you to merge two
1283
config files together.
1285
You would typically use this to create a default ConfigObj and then merge
1286
in user settings. This way users only need to specify values that are
1287
different from the default.
1295
# def_cfg contains your default config settings
1296
# user_cfg contains the user settings
1297
cfg = ConfigObj(def_cfg)
1298
usr = ConfigObj(user_cfg)
1303
cfg now contains a combination of the default settings and the user
1306
The user settings will have overwritten any of the default ones.
1313
This method can be used to transform values and names. See `walking a
1314
section`_ for examples and explanation.
1318
``decode(encoding)``
1320
This method decodes names and values into Unicode objects, using the
1325
``encode(encoding)``
1327
This method is the opposite of ``decode`` {sm;:!:}.
1329
It encodes names and values using the supplied encoding. If any of your
1330
names/values are strings rather than Unicode, Python will have to do an
1331
implicit decode first. (This method uses ``sys.defaultencoding`` for
1338
Returns ``True`` if the key contains a string that represents ``True``, or
1339
is the ``True`` object.
1341
Returns ``False`` if the key contains a string that represents ``False``,
1342
or is the ``False`` object.
1344
Raises a ``ValueError`` if the key contains anything else.
1346
Strings that represent ``True`` are (not case sensitive) : ::
1350
Strings that represent ``False`` are : ::
1356
In ConfigObj 4.1.0, this method was called ``istrue``. That method is
1357
now deprecated and will issue a warning when used. It will go away
1358
in a future release.
1364
This returns the value contained in the specified key as an integer.
1366
It raises a ``ValueError`` if the conversion can't be done.
1372
This returns the value contained in the specified key as a float.
1374
It raises a ``ValueError`` if the conversion can't be done.
1376
* **restore_default**
1378
``restore_default(key)``
1380
Restore (and return) the default value for the specified key.
1382
This method will only work for a ConfigObj that was created
1383
with a configspec and has been validated.
1385
If there is no default value for this key, ``KeyError`` is raised.
1387
* **restore_defaults**
1389
``restore_defaults()``
1391
Recursively restore default values to all members
1394
This method will only work for a ConfigObj that was created
1395
with a configspec and has been validated.
1397
It doesn't delete or modify entries without default values.
1405
The walk method allows you to call a function on every member/name.
1411
walk(function, raise_errors=True,
1412
call_on_sections=False, **keywargs):
1416
``walk`` is a method of the ``Section`` object. This means it is also a method
1419
It walks through every member and calls a function on the keyword and value. It
1420
walks recursively through subsections.
1422
It returns a dictionary of all the computed values.
1424
If the function raises an exception, the default is to propagate the error, and
1425
stop. If ``raise_errors=False`` then it sets the return value for that keyword
1426
to ``False`` instead, and continues. This is similar to the way validation_
1429
Your function receives the arguments ``(section, key)``. The current value is
1430
then ``section[key]`` [#]_. Any unrecognised keyword arguments you pass to
1431
walk, are passed on to the function.
1433
Normally ``walk`` just recurses into subsections. If you are transforming (or
1434
checking) names as well as values, then you want to be able to change the names
1435
of sections. In this case set ``call_on_sections`` to ``True``. Now, on
1436
encountering a sub-section, *first* the function is called for the *whole*
1437
sub-section, and *then* it recurses into it's members. This means your function
1438
must be able to handle receiving dictionaries as well as strings and lists.
1440
If you are using the return value from ``walk`` *and* ``call_on_sections``,
1441
note that walk discards the return value when it calls your function.
1445
You can use ``walk`` to transform the names of members of a section
1446
but you mustn't add or delete members.
1452
Examples that use the walk method are the ``encode`` and ``decode`` methods.
1453
They both define a function and pass it to walk. Because these functions
1454
transform names as well as values (from byte strings to Unicode) they set
1455
``call_on_sections=True``.
1457
To see how they do it, *read the source Luke* {sm;:cool:}.
1459
You can use this for transforming all values in your ConfigObj. For example
1460
you might like the nested lists from ConfigObj 3. This was provided by the
1461
listquote_ module. You could switch off the parsing for list values
1462
(``list_values=False``) and use listquote to parse every value.
1464
Another thing you might want to do is use the Python escape codes in your
1465
values. You might be *used* to using ``\n`` for line feed and ``\t`` for tab.
1466
Obviously we'd need to decode strings that come from the config file (using the
1467
escape codes). Before writing out we'll need to put the escape codes back in
1470
As an example we'll write a function to use with walk, that encodes or decodes
1471
values using the ``string-escape`` codec.
1473
The function has to take each value and set the new value. As a bonus we'll
1474
create one function that will do decode *or* encode depending on a keyword
1477
We don't want to work with section names, we're only transforming values, so
1478
we can leave ``call_on_sections`` as ``False``. This means the two datatypes we
1479
have to handle are strings and lists, we can ignore everything else. (We'll
1480
treat tuples as lists as well).
1482
We're not using the return values, so it doesn't need to return anything, just
1483
change the values if appropriate.
1489
def string_escape(section, key, encode=False):
1491
A function to encode or decode using the 'string-escape' codec.
1492
To be passed to the walk method of a ConfigObj.
1493
By default it decodes.
1494
To encode, pass in the keyword argument ``encode=True``.
1497
# is it a type we can work with
1498
# NOTE: for platforms where Python > 2.2
1499
# you can use basestring instead of (str, unicode)
1500
if not isinstance(val, (str, unicode, list, tuple)):
1503
elif isinstance(val, (str, unicode)):
1506
section[key] = val.decode('string-escape')
1508
section[key] = val.encode('string-escape')
1510
# it must be a list or tuple!
1511
# we'll be lazy and create a new list
1513
# we'll check every member of the list
1515
if isinstance(entry, (str, unicode)):
1517
newval.append(entry.decode('string-escape'))
1519
newval.append(entry.encode('string-escape'))
1521
newval.append(entry)
1523
section[key] = newval
1525
# assume we have a ConfigObj called ``config``
1528
config.walk(string_escape)
1531
# Because ``walk`` doesn't recognise the ``encode`` argument
1532
# it passes it to our function.
1533
config.walk(string_escape, encode=True)
1537
Here's a simple example of using ``walk`` to transform names and values. One
1538
usecase of this would be to create a *standard* config file with placeholders
1539
for section and keynames. You can then use walk to create new config files
1540
and change values and member names :
1546
# We use 'XXXX' as a placeholder
1548
XXXXkey1 = XXXXvalue1
1549
XXXXkey2 = XXXXvalue2
1550
XXXXkey3 = XXXXvalue3
1552
XXXXkey1 = XXXXvalue1
1553
XXXXkey2 = XXXXvalue2
1554
XXXXkey3 = XXXXvalue3
1556
XXXXkey1 = XXXXvalue1
1557
XXXXkey2 = XXXXvalue2
1558
XXXXkey3 = XXXXvalue3
1560
XXXXkey1 = XXXXvalue1
1561
XXXXkey2 = XXXXvalue2
1562
XXXXkey3 = XXXXvalue3
1564
cfg = ConfigObj(config)
1566
def transform(section, key):
1568
newkey = key.replace('XXXX', 'CLIENT1')
1569
section.rename(key, newkey)
1570
if isinstance(val, (tuple, list, dict)):
1573
val = val.replace('XXXX', 'CLIENT1')
1574
section[newkey] = val
1576
cfg.walk(transform, call_on_sections=True)
1578
ConfigObj({'CLIENT1key1': 'CLIENT1value1', 'CLIENT1key2': 'CLIENT1value2',
1579
'CLIENT1key3': 'CLIENT1value3',
1580
'CLIENT1section1': {'CLIENT1key1': 'CLIENT1value1',
1581
'CLIENT1key2': 'CLIENT1value2', 'CLIENT1key3': 'CLIENT1value3'},
1582
'CLIENT1section2': {'CLIENT1key1': 'CLIENT1value1',
1583
'CLIENT1key2': 'CLIENT1value2', 'CLIENT1key3': 'CLIENT1value3',
1584
'CLIENT1section1': {'CLIENT1key1': 'CLIENT1value1',
1585
'CLIENT1key2': 'CLIENT1value2', 'CLIENT1key3': 'CLIENT1value3'}}})
1593
There are several places where ConfigObj may raise exceptions (other than
1596
1) If a configspec filename you pass in doesn't exist, or a config file
1597
filename doesn't exist *and* ``file_error=True``, an ``IOError`` will be
1600
2) If you try to set a non-string key, or a non string value when
1601
``stringify=False``, a ``TypeError`` will be raised.
1603
3) A badly built config file will cause parsing errors.
1605
4) A parsing error can also occur when reading a configspec.
1607
5) In string interpolation you can specify a value that doesn't exist, or
1608
create circular references (recursion).
1610
6) If you have a ``__many__`` repeated section with other section definitions
1611
(in a configspec), a ``RepeatSectionError`` will be raised.
1613
Number 5 (which is actually two different types of exceptions) is documented
1614
in `String Interpolation`_.
1616
Number 6 is explained in the validation_ section.
1618
*This* section is about errors raised during parsing.
1620
The base error class is ``ConfigObjError``. This is a subclass of
1621
``SyntaxError``, so you can trap for ``SyntaxError`` without needing to
1622
directly import any of the ConfigObj exceptions.
1624
The following other exceptions are defined (all deriving from
1625
``ConfigObjError``) :
1629
This error indicates either a mismatch in the brackets in a section marker,
1630
or an excessive level of nesting.
1634
This error indicates that a line is badly written. It is neither a valid
1635
``key = value`` line, nor a valid section marker line, nor a comment line.
1637
* ``DuplicateError``
1639
The keyword or section specified already exists.
1641
* ``ConfigspecError``
1643
An error occurred whilst parsing a configspec.
1647
An error occurred when parsing a value in `unrepr mode`_.
1651
``reload`` was called on a ConfigObj instance that doesn't have a valid
1654
When parsing a configspec, ConfigObj will stop on the first error it
1655
encounters. It will raise a ``ConfigspecError``. This will have an ``error``
1656
attribute, which is the actual error that was raised.
1658
Behaviour when parsing a config file depends on the option ``raise_errors``.
1659
If ConfigObj encounters an error while parsing a config file:
1661
If ``raise_errors=True`` then ConfigObj will raise the appropriate error
1662
and parsing will stop.
1664
If ``raise_errors=False`` (the default) then parsing will continue to the
1665
end and *all* errors will be collected.
1667
If ``raise_errors`` is False and multiple errors are found a ``ConfigObjError``
1668
is raised. The error raised has a ``config`` attribute, which is the parts of
1669
the ConfigObj that parsed successfully. It also has an attribute ``errors``,
1670
which is a list of *all* the errors raised. Each entry in the list is an
1671
instance of the appropriate error type. Each one has the following attributes
1672
(useful for delivering a sensible error message to your user) :
1674
* ``line``: the original line that caused the error.
1676
* ``line_number``: its number in the config file.
1678
* ``message``: the error message that accompanied the error.
1680
If only one error is found, then that error is re-raised. The error still has
1681
the ``config`` and ``errors`` attributes. This means that your error handling
1682
code can be the same whether one error is raised in parsing , or several.
1684
It also means that in the most common case (a single error) a useful error
1685
message will be raised.
1689
One wrongly written line could break the basic structure of your config
1690
file. This could cause every line after it to flag an error, so having a
1691
list of all the lines that caused errors may not be as useful as it sounds.
1700
The system of configspecs can seem confusing at first, but is actually
1701
quite simple and powerful. For a concrete example of how to use it, you may
1702
find this blog entry helpful :
1703
`Transforming Values with ConfigObj <http://www.voidspace.org.uk/python/weblog/arch_d7_2006_03_04.shtml#e257>`_.
1705
Validation is done through a combination of the configspec_ and a ``Validator``
1706
object. For this you need *validate.py* [#]_. See downloading_ if you don't
1709
Validation can perform two different operations :
1711
1) Check that a value meets a specification. For example, check that a value
1712
is an integer between one and six, or is a choice from a specific set of
1715
2) It can convert the value into the type required. For example, if one of
1716
your values is a port number, validation will turn it into an integer for
1719
So validation can act as a transparent layer between the datatypes of your
1720
application configuration (boolean, integers, floats, etc) and the text format
1721
of your config file.
1727
The ``validate`` method checks members against an entry in the configspec. Your
1728
configspec therefore resembles your config file, with a check for every member.
1730
In order to perform validation you need a ``Validator`` object. This has
1731
several useful built-in check functions. You can also create your own custom
1732
functions and register them with your Validator object.
1734
Each check is the name of one of these functions, including any parameters and
1735
keyword arguments. The configspecs look like function calls, and they map to
1738
The basic datatypes that an un-extended Validator can test for are :
1740
* boolean values (True and False)
1741
* integers (including minimum and maximum values)
1742
* floats (including min and max)
1743
* strings (including min and max length)
1744
* IP addresses (v4 only)
1746
It can also handle lists of these types and restrict a value to being one from
1749
An example configspec is going to look something like : ::
1751
port = integer(0, 100)
1752
user = string(max=25)
1753
mode = option('quiet', 'loud', 'silent')
1755
You can specify default values, and also have the same configspec applied to
1756
several sections. This is called `repeated sections`_.
1758
For full details on writing configspecs, please refer to the `validate.py
1763
Your configspec is read by ConfigObj in the same way as a config file.
1765
That means you can do interpolation *within* your configspec.
1767
In order to allow this, checks in the 'DEFAULT' section (of the root level
1768
of your configspec) are *not* used.
1770
If you need to specify the encoding of your configspec, then you can pass in a
1771
ConfigObj instance as your configspec. When you read your configspec file, you
1772
*must* specify ``list_values=False``.
1777
from configobj import ConfigObj
1778
configspec = ConfigObj(configspecfilename, encoding='UTF8',
1780
config = ConfigObj(filename, configspec=configspec)
1783
.. _validate.py documentation: http://www.voidspace.org.uk/python/validate.html
1789
By default, validation does type conversion. This means that if you specify
1790
``integer`` as the check, then calling validate_ will actually change the value
1791
to an integer (so long as the check succeeds).
1793
It also means that when you call the write_ method, the value will be converted
1794
back into a string using the ``str`` function.
1796
To switch this off, and leave values as strings after validation, you need to
1797
set the stringify_ attribute to ``False``. If this is the case, attempting to
1798
set a value to a non-string will raise an error.
1804
You can set a default value in your check. If the value is missing from the
1805
config file then this value will be used instead. This means that your user
1806
only has to supply values that differ from the defaults.
1808
If you *don't* supply a default then for a value to be missing is an error,
1809
and this will show in the `return value`_ from validate.
1811
Additionally you can set the default to be ``None``. This means the value will
1812
be set to ``None`` (the object) *whichever check is used*. (It will be set to
1813
``''`` rather than ``None`` if stringify_ is ``False``). You can use this
1814
to easily implement optional values in your config files. ::
1816
port = integer(0, 100, default=80)
1817
user = string(max=25, default=0)
1818
mode = option('quiet', 'loud', 'silent', default='loud')
1819
nick = string(default=None)
1823
Because the default goes through type conversion, it also has to pass the
1826
Note that ``default=None`` is case sensitive.
1832
It's possible that you will want to specify a list as a default value. To avoid
1833
confusing syntax with commas and quotes you use a list constructor to specify
1834
that keyword arguments are lists. This includes the ``default`` value. This
1835
makes checks look something like : ::
1837
checkname(default=list('val1', 'val2', 'val3'))
1839
This works with all keyword arguments, but is most useful for default values.
1845
Repeated sections are a way of specifying a configspec for a section that
1846
should be applied to *all* subsections in the same section.
1848
The easiest way of explaining this is to give an example. Suppose you have a
1849
config file that describes a dog. That dog has various attributes, but it can
1850
also have many fleas. You don't know in advance how many fleas there will be,
1851
or what they will be called, but you want each flea validated against the same
1854
We can define a section called *fleas*. We want every flea in that section
1855
(every sub-section) to have the same configspec applied to it. We do this by
1856
defining a single section called ``__many__``. ::
1859
name = string(default=Rover)
1860
age = float(0, 99, default=0)
1865
bloodsucker = boolean(default=True)
1866
children = integer(default=10000)
1867
size = option(small, tiny, micro, default=tiny)
1869
Every flea on our dog will now be validated using the ``__many__`` configspec.
1871
If you define another sub-section in a section *as well as* a ``__many__`` then
1872
you will get an error.
1874
``__many__`` sections can have sub-sections, including their own ``__many__``
1875
sub-sections. Defaults work in the normal way in repeated sections.
1881
Because you can specify default values in your configspec, you can use
1882
ConfigObj to write out default config files for your application.
1884
However, normally values supplied from a default in a configspec are *not*
1885
written out by the ``write`` method.
1887
To do this, you need to specify ``copy=True`` when you call validate. As well
1888
as not marking values as default, all the comments in the configspec file
1889
will be copied into your ConfigObj instance.
1894
from configobj import ConfigObj
1895
from validate import Validator
1897
config = ConfigObj(configspec='default.ini')
1898
config.filename = 'new_default.ini'
1899
config.validate(vdt, copy=True)
1904
Validation and Interpolation
1905
----------------------------
1907
String interpolation and validation don't play well together. When validation
1908
changes type it sets the value. If the value uses interpolation, then the
1909
interpolation reference would normally be overwritten. Calling ``write`` would
1910
then use the absolute value and the interpolation reference would be lost.
1912
As a compromise - if the value is unchanged by validation then it is not reset.
1913
This means strings that pass through validation unmodified will not be
1914
overwritten. If validation changes type - the value has to be overwritten, and
1915
any interpolation references are lost {sm;:-(}.
1921
You may not need a full validation process, but still want to check if all the
1922
expected values are present.
1924
Provided as part of the ConfigObj module is the ``SimpleVal`` object. This has
1925
a dummy ``test`` method that always passes.
1927
The only reason a test will fail is if the value is missing. The return value
1928
from ``validate`` will either be ``True``, meaning all present, or a dictionary
1929
with ``False`` for all missing values/sections.
1931
To use it, you still need to pass in a valid configspec when you create the
1932
ConfigObj, but just set all the values to ``''``. Then create an instance of
1933
``SimpleVal`` and pass it to the ``validate`` method.
1935
As a trivial example if you had the following config file : ::
1937
# config file for an application
1941
top_level_domain = org.uk
1943
You would write the following configspec : ::
1948
top_level_domain = ''
1954
config = Configobj(filename, configspec=configspec)
1956
test = config.validate(val)
1958
print 'All values present.'
1960
print 'No values present!'
1963
if test[entry] == False:
1964
print '"%s" missing.' % entry
1972
Many config files from other applications allow empty values. As of version
1973
4.3.0, ConfigObj will read these as an empty string.
1975
A new option/attribute has been added (``write_empty_values``) to allow
1976
ConfigObj to write empty strings as empty values.
1981
from configobj import ConfigObj
1986
config = ConfigObj(cfg)
1988
ConfigObj({'key': '', 'key2': ''})
1990
config.write_empty_values = True
1991
for line in config.write():
2002
The ``unrepr`` option allows you to store and retrieve the basic Python
2003
data-types using config files. It has to use a slightly different syntax to
2004
normal ConfigObj files. Unsurprisingly it uses Python syntax.
2006
This means that lists are different (they are surrounded by square brackets),
2007
and strings *must* be quoted.
2009
The types that ``unrepr`` can work with are :
2011
| strings, lists tuples
2013
| dictionaries, integers, floats
2014
| longs and complex numbers
2016
You can't store classes, types or instances.
2018
``unrepr`` uses ``repr(object)`` to write out values, so it currently *doesn't*
2019
check that you are writing valid objects. If you attempt to read an unsupported
2020
value, ConfigObj will raise a ``configobj.UnknownType`` exception.
2022
Values that are triple quoted cased. The triple quotes are removed *before*
2023
converting. This means that you can use triple quotes to write dictionaries
2024
over several lines in your config files. They won't be written like this
2027
If you are writing config files by hand, for use with ``unrepr``, you should
2028
be aware of the following differences from normal ConfigObj syntax :
2030
| List : ``['A List', 'With', 'Strings']``
2031
| Strings : ``"Must be quoted."``
2032
| Backslash : ``"The backslash must be escaped \\"``
2034
These all follow normal Python syntax.
2036
In unrepr mode *inline comments* are not saved. This is because lines are
2037
parsed using the `compiler package <http://docs.python.org/lib/compiler.html>`_
2038
which discards comments.
2041
String Interpolation
2042
====================
2044
ConfigObj allows string interpolation *similar* to the way ``ConfigParser``
2045
or ``string.Template`` work. The value of the ``interpolation`` attribute
2046
determines which style of interpolation you want to use. Valid values are
2047
"ConfigParser" or "Template" (case-insensitive, so "configparser" and
2048
"template" will also work). For backwards compatibility reasons, the value
2049
``True`` is also a valid value for the ``interpolation`` attribute, and
2050
will select ``ConfigParser``-style interpolation. At some undetermined point
2051
in the future, that default *may* change to ``Template``-style interpolation.
2053
For ``ConfigParser``-style interpolation, you specify a value to be
2054
substituted by including ``%(name)s`` in the value.
2056
For ``Template``-style interpolation, you specify a value to be substituted
2057
by including ``${cl}name{cr}`` in the value. Alternately, if 'name' is a valid
2058
Python identifier (i.e., is composed of nothing but alphanumeric characters,
2059
plus the underscore character), then the braces are optional and the value
2060
can be written as ``$name``.
2062
Note that ``ConfigParser``-style interpolation and ``Template``-style
2063
interpolation are mutually exclusive; you cannot have a configuration file
2064
that's a mix of one or the other. Pick one and stick to it. ``Template``-style
2065
interpolation is simpler to read and write by hand, and is recommended if
2066
you don't have a particular reason to use ``ConfigParser``-style.
2068
Interpolation checks first the current section to see if ``name`` is the key
2069
to a value. ('name' is case sensitive).
2071
If it doesn't find it, next it checks the 'DEFAULT' sub-section of the current
2074
If it still doesn't find it, it moves on to check the parent section and the
2075
parent section's 'DEFAULT' subsection, and so on all the way up to the main
2078
If the value specified isn't found in any of these locations, then a
2079
``MissingInterpolationOption`` error is raised (a subclass of
2080
``ConfigObjError``).
2082
If it is found then the returned value is also checked for substitutions. This
2083
allows you to make up compound values (for example directory paths) that use
2084
more than one default value. It also means it's possible to create circular
2085
references. If there are any circular references which would cause an infinite
2086
interpolation loop, an ``InterpolationLoopError`` is raised.
2088
Both of these errors are subclasses of ``InterpolationError``, which is a
2089
subclass of ``ConfigObjError``.
2091
String interpolation and validation don't play well together. This is because
2092
validation overwrites values - and so may erase the interpolation references.
2093
See `Validation and Interpolation`_. (This can only happen if validation
2094
has to *change* the value).
2100
Any line that starts with a '#', possibly preceded by whitespace, is a comment.
2102
If a config file starts with comments then these are preserved as the
2105
If a config file ends with comments then these are preserved as the
2108
Every key or section marker may have lines of comments immediately above it.
2109
These are saved as the ``comments`` attribute of the section. Each member is a
2112
You can also have a comment inline with a value. These are saved as the
2113
``inline_comments`` attribute of the section, with one entry per member of the
2116
Subsections (section markers in the config file) can also have comments.
2118
See `Section Attributes`_ for more on these attributes.
2120
These comments are all written back out by the ``write`` method.
2128
flatten_errors(cfg, res)
2130
Validation_ is a powerful way of checking that the values supplied by the user
2133
The validate_ method returns a results dictionary that represents pass or fail
2134
for each value. This doesn't give you any information about *why* the check
2137
``flatten_errors`` is an example function that turns a results dictionary into
2138
a flat list, that only contains values that *failed*.
2140
``cfg`` is the ConfigObj instance being checked, ``res`` is the results
2141
dictionary returned by ``validate``.
2143
It returns a list of keys that failed. Each member of the list is a tuple : ::
2145
([list of sections...], key, result)
2147
If ``validate`` was called with ``preserve_errors=False`` (the default)
2148
then ``result`` will always be ``False``.
2150
*list of sections* is a flattened list of sections that the key was found
2153
If the section was missing then key will be ``None``.
2155
If the value (or section) was missing then ``result`` will be ``False``.
2157
If ``validate`` was called with ``preserve_errors=True`` and a value
2158
was present, but failed the check, then ``result`` will be the exception
2159
object returned. You can use this as a string that describes the failure.
2163
*The value "3" is of the wrong type*.
2169
The output from ``flatten_errors`` is a list of tuples.
2171
Here is an example of how you could present this information to the user.
2177
vtor = validate.Validator()
2178
# ini is your config file - cs is the configspec
2179
cfg = ConfigObj(ini, configspec=cs)
2180
res = cfg.validate(vtor, preserve_errors=True)
2181
for entry in flatten_errors(cfg, res):
2182
# each entry is a tuple
2183
section_list, key, error = entry
2185
section_list.append(key)
2187
section_list.append('[missing section]')
2188
section_string = ', '.join(section_list)
2190
error = 'Missing value or section.'
2191
print section_string, ' = ', error
2199
ConfigObj 3 is now deprecated in favour of ConfigObj 4. I can fix bugs in
2200
ConfigObj 3 if needed, though.
2202
For anyone who still needs it, you can download it here: `ConfigObj 3.3.1`_
2204
You can read the old docs at : `ConfigObj 3 Docs`_
2206
.. _ConfigObj 3.3.1: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj3.zip
2207
.. _ConfigObj 3 Docs: http://www.voidspace.org.uk/python/configobj3.html
2213
ConfigObj 4 is written by (and copyright) `Michael Foord`_ and
2216
Particularly thanks to Nicola Larosa for help on the config file spec, the
2217
validation system and the doctests.
2219
*validate.py* was originally written by Michael Foord and Mark Andrews.
2221
Thanks to others for input and bugfixes.
2227
ConfigObj, and related files, are licensed under the BSD license. This is a
2228
very unrestrictive license, but it comes with the usual disclaimer. This is
2229
free software: test it, break it, just don't blame us if it eats your data !
2230
Of course if it does, let us know and we'll fix the problem so it doesn't
2231
happen to anyone else {sm;:-)}. ::
2233
Copyright (c) 2004 - 2008, Michael Foord & Nicola Larosa
2234
All rights reserved.
2236
Redistribution and use in source and binary forms, with or without
2237
modification, are permitted provided that the following conditions are
2241
* Redistributions of source code must retain the above copyright
2242
notice, this list of conditions and the following disclaimer.
2244
* Redistributions in binary form must reproduce the above
2245
copyright notice, this list of conditions and the following
2246
disclaimer in the documentation and/or other materials provided
2247
with the distribution.
2249
* Neither the name of Michael Foord nor Nicola Larosa
2250
may be used to endorse or promote products derived from this
2251
software without specific prior written permission.
2253
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
2254
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
2255
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
2256
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
2257
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
2258
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
2259
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
2260
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
2261
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
2262
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
2263
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
2265
You should also be able to find a copy of this license at : `BSD License`_
2267
.. _BSD License: http://www.voidspace.org.uk/python/license.shtml
2273
Better support for configuration from multiple files, including tracking
2274
*where* the original file came from and writing changes to the correct
2277
Make ``newline`` an option (as well as an attribute) ?
2279
``UTF16`` encoded files, when returned as a list of lines, will have the
2280
BOM at the start of every line. Should this be removed from all but the
2283
Option to set warning type for unicode decode ? (Defaults to strict).
2285
A method to optionally remove uniform indentation from multiline values.
2286
(do as an example of using ``walk`` - along with string-escape)
2288
Should the results dictionary from validate be an ordered dictionary if
2289
`odict <http://www.voidspace.org.uk/python/odict.html>`_ is available ?
2291
Implement some of the sequence methods (which include slicing) from the
2294
Preserve line numbers of values (and possibly the original text of each value).
2302
Please file any bug reports to `Michael Foord`_ or the **ConfigObj**
2305
There is currently no way to specify the encoding of a configspec file.
2307
When using ``copy`` mode for validation, it won't copy ``DEFAULT``
2308
sections. This is so that you *can* use interpolation in configspec
2311
``validate`` doesn't report *extra* values or sections.
2313
You can't have a keyword with the same name as a section (in the same
2314
section). They are both dictionary keys - so they would overlap.
2316
ConfigObj doesn't quote and unquote values if ``list_values=False``.
2317
This means that leading or trailing whitespace in values will be lost when
2318
writing. (Unless you manually quote).
2320
Interpolation checks first the current section, then the 'DEFAULT' subsection
2321
of the current section, before moving on to the current section's parent and
2324
Does it matter that we don't support the ':' divider, which is supported
2325
by ``ConfigParser`` ?
2327
String interpolation and validation don't play well together. When
2328
validation changes type it sets the value. This will correctly fetch the
2329
value using interpolation - but then overwrite the interpolation reference.
2330
If the value is unchanged by validation (it's a string) - but other types
2337
This is an abbreviated changelog showing the major releases up to version 4.
2338
From version 4 it lists all releases and changes.
2341
2008/02/05 - Version 4.5.1
2342
--------------------------
2344
Distribution updated to include version 0.3.1 of validate_. This means that
2345
Unicode configspecs now work.
2348
2008/02/05 - Version 4.5.0
2349
--------------------------
2351
ConfigObj will now guarantee that files will be written terminated with a
2354
ConfigObj will no longer attempt to import the ``validate`` module, until/unless
2355
you call ``ConfigObj.validate`` with ``preserve_errors=True``. This makes it
2358
New methods ``restore_default`` and ``restore_defaults``. ``restore_default``
2359
resets an entry to its default value (and returns that value). ``restore_defaults``
2360
resets all entries to their default value. It doesn't modify entries without a
2361
default value. You must have validated a ConfigObj (which populates the
2362
``default_values`` dictionary) before calling these methods.
2364
BUGFIX: Proper quoting of keys, values and list values that contain hashes
2365
(when writing). When ``list_values=False``, values containing hashes are
2368
Added the ``reload`` method. This reloads a ConfigObj from file. If the filename
2369
attribute is not set then a ``ReloadError`` (a new exception inheriting from
2370
``IOError``) is raised.
2372
BUGFIX: Files are read in with 'rb' mode, so that native/non-native line endings work!
2374
Minor efficiency improvement in ``unrepr`` mode.
2376
Added missing docstrings for some overidden dictionary methods.
2378
Added the ``reset`` method. This restores a ConfigObj to a freshly created state.
2380
Removed old CHANGELOG file.
2383
2007/02/04 - Version 4.4.0
2384
--------------------------
2386
Official release of 4.4.0
2389
2006/12/17 - Version 4.3.3-alpha4
2390
---------------------------------
2394
Allowed arbitrary indentation in the ``indent_type`` parameter, removed the
2395
``NUM_INDENT_SPACES`` and ``MAX_INTERPOL_DEPTH`` (a leftover) constants,
2396
added indentation tests (including another docutils workaround, sigh), updated
2401
Made the import of ``compiler`` conditional so that ``ConfigObj`` can be used
2402
with `IronPython <http://www.codeplex.com/IronPython>`_.
2405
2006/12/17 - Version 4.3.3-alpha3
2406
---------------------------------
2410
Added a missing ``self.`` in the _handle_comment method and a related test,
2411
per Sourceforge bug #1523975.
2414
2006/12/09 - Version 4.3.3-alpha2
2415
---------------------------------
2419
Changed interpolation search strategy, based on this patch by Robin Munn:
2420
http://sourceforge.net/mailarchive/message.php?msg_id=17125993
2423
2006/12/09 - Version 4.3.3-alpha1
2424
---------------------------------
2428
Added Template-style interpolation, with tests, based on this patch by
2429
Robin Munn: http://sourceforge.net/mailarchive/message.php?msg_id=17125991
2430
(awful archives, bad Sourceforge, bad).
2433
2006/06/04 - Version 4.3.2
2434
--------------------------
2436
Changed error handling, if parsing finds a single error then that error will
2437
be re-raised. That error will still have an ``errors`` and a ``config``
2440
Fixed bug where '\\n' terminated files could be truncated.
2442
Bugfix in ``unrepr`` mode, it couldn't handle '#' in values. (Thanks to
2443
Philippe Normand for the report.)
2445
As a consequence of this fix, ConfigObj doesn't now keep inline comments in
2446
``unrepr`` mode. This is because the parser in the `compiler package`_
2447
doesn't keep comments. {sm;:-)}
2449
Error messages are now more useful. They tell you the number of parsing errors
2450
and the line number of the first error. (In the case of multiple errors.)
2452
Line numbers in exceptions now start at 1, not 0.
2454
Errors in ``unrepr`` mode are now handled the same way as in the normal mode.
2455
The errors stored will be an ``UnreprError``.
2458
2006/04/29 - Version 4.3.1
2459
--------------------------
2461
Added ``validate.py`` back into ``configobj.zip``. (Thanks to Stewart
2464
Updated to `validate.py`_ 0.2.2.
2466
Preserve tuples when calling the ``dict`` method. (Thanks to Gustavo Niemeyer.)
2468
Changed ``__repr__`` to return a string that contains ``ConfigObj({ ... })``.
2470
Change so that an options dictionary isn't modified by passing it to ConfigObj.
2471
(Thanks to Artarious.)
2473
Added ability to handle negative integers in ``unrepr``. (Thanks to Kevin
2477
2006/03/24 - Version 4.3.0
2478
--------------------------
2480
Moved the tests and the CHANGELOG (etc) into a separate file. This has reduced
2481
the size of ``configobj.py`` by about 40%.
2483
Added the ``unrepr`` mode to reading and writing config files. Thanks to Kevin
2484
Dangoor for this suggestion.
2486
Empty values are now valid syntax. They are read as an empty string ``''``.
2487
(``key =``, or ``key = # comment``.)
2489
``validate`` now honours the order of the configspec.
2491
Added the ``copy`` mode to validate. Thanks to Louis Cordier for this
2494
Fixed bug where files written on windows could be given ``'\r\r\n'`` line
2497
Fixed bug where last occurring comment line could be interpreted as the
2498
final comment if the last line isn't terminated.
2500
Fixed bug where nested list values would be flattened when ``write`` is
2501
called. Now sub-lists have a string representation written instead.
2503
Deprecated ``encode`` and ``decode`` methods instead.
2505
You can now pass in a ConfigObj instance as a configspec (remember to read
2506
the configspec file using ``list_values=False``).
2508
Sorted footnotes in the docs.
2511
2006/02/16 - Version 4.2.0
2512
--------------------------
2514
Removed ``BOM_UTF8`` from ``__all__``.
2516
The ``BOM`` attribute has become a boolean. (Defaults to ``False``.) It is
2517
*only* ``True`` for the ``UTF16/UTF8`` encodings.
2519
File like objects no longer need a ``seek`` attribute.
2521
Full unicode support added. New options/attributes ``encoding``,
2522
``default_encoding``.
2524
ConfigObj no longer keeps a reference to file like objects. Instead the
2525
``write`` method takes a file like object as an optional argument. (Which
2526
will be used in preference of the ``filename`` attribute if that exists as
2529
utf16 files decoded to unicode.
2531
If ``BOM`` is ``True``, but no encoding specified, then the utf8 BOM is
2532
written out at the start of the file. (It will normally only be ``True`` if
2533
the utf8 BOM was found when the file was read.)
2535
Thanks to Aaron Bentley for help and testing on the unicode issues.
2537
File paths are *not* converted to absolute paths, relative paths will
2538
remain relative as the ``filename`` attribute.
2540
Fixed bug where ``final_comment`` wasn't returned if ``write`` is returning
2543
Deprecated ``istrue``, replaced it with ``as_bool``.
2545
Added ``as_int`` and ``as_float``.
2548
2005/12/14 - Version 4.1.0
2549
--------------------------
2551
Added ``merge``, a recursive update.
2553
Added ``preserve_errors`` to ``validate`` and the ``flatten_errors``
2556
Thanks to Matthew Brett for suggestions and helping me iron out bugs.
2558
Fixed bug where a config file is *all* comment, the comment will now be
2559
``initial_comment`` rather than ``final_comment``.
2561
Validation no longer done on the 'DEFAULT' section (only in the root level).
2562
This allows interpolation in configspecs.
2564
Also use the new list syntax in validate_ 0.2.1. (For configspecs).
2567
2005/12/02 - Version 4.0.2
2568
--------------------------
2570
Fixed bug in ``create_empty``. Thanks to Paul Jimenez for the report.
2573
2005/11/05 - Version 4.0.1
2574
--------------------------
2576
Fixed bug in ``Section.walk`` when transforming names as well as values.
2578
Added the ``istrue`` method. (Fetches the boolean equivalent of a string
2581
Fixed ``list_values=False`` - they are now only quoted/unquoted if they
2582
are multiline values.
2584
List values are written as ``item, item`` rather than ``item,item``.
2587
2005/10/17 - Version 4.0.0
2588
--------------------------
2590
**ConfigObj 4.0.0 Final**
2592
Fixed bug in ``setdefault``. When creating a new section with setdefault the
2593
reference returned would be to the dictionary passed in *not* to the new
2594
section. Bug fixed and behaviour documented.
2596
Obscure typo/bug fixed in ``write``. Wouldn't have affected anyone though.
2599
2005/09/09 - Version 4.0.0 beta 5
2600
---------------------------------
2602
Removed ``PositionError``.
2604
Allowed quotes around keys as documented.
2606
Fixed bug with commas in comments. (matched as a list value)
2609
2005/09/07 - Version 4.0.0 beta 4
2610
---------------------------------
2612
Fixed bug in ``__delitem__``. Deleting an item no longer deletes the
2613
``inline_comments`` attribute.
2615
Fixed bug in initialising ConfigObj from a ConfigObj.
2617
Changed the mailing list address.
2620
2005/08/28 - Version 4.0.0 beta 3
2621
---------------------------------
2623
Interpolation is switched off before writing out files.
2625
Fixed bug in handling ``StringIO`` instances. (Thanks to report from
2628
Moved the doctests from the ``__init__`` method to a separate function.
2629
(For the sake of IDE calltips).
2632
2005/08/25 - Version 4.0.0 beta 2
2633
---------------------------------
2635
Amendments to *validate.py*.
2637
First public release.
2640
2005/08/21 - Version 4.0.0 beta 1
2641
---------------------------------
2643
Reads nested subsections to any depth.
2647
Simplified options and methods.
2651
Faster, smaller, and better parser.
2653
Validation greatly improved. Includes:
2659
Improved error handling.
2661
Plus lots of other improvements. {sm;:grin:}
2664
2004/05/24 - Version 3.0.0
2665
--------------------------
2667
Several incompatible changes: another major overhaul and change. (Lots of
2668
improvements though).
2670
Added support for standard config files with sections. This has an entirely
2671
new interface: each section is a dictionary of values.
2673
Changed the update method to be called writein: update clashes with a dict
2676
Made various attributes keyword arguments, added several.
2678
Configspecs and orderlists have changed a great deal.
2680
Removed support for adding dictionaries: use update instead.
2682
Now subclasses a new class called caselessDict. This should add various
2683
dictionary methods that could have caused errors before.
2685
It also preserves the original casing of keywords when writing them back out.
2687
Comments are also saved using a ``caselessDict``.
2689
Using a non-string key will now raise a ``TypeError`` rather than converting
2692
Added an exceptions keyword for *much* better handling of errors.
2694
Made ``creatempty=False`` the default.
2696
Now checks indict *and* any keyword args. Keyword args take precedence over
2699
``' ', ':', '=', ','`` and ``'\t'`` are now all valid dividers where the
2700
keyword is unquoted.
2702
ConfigObj now does no type checking against configspec when you set items.
2704
delete and add methods removed (they were unnecessary).
2706
Docs rewritten to include all this gumph and more; actually ConfigObj is
2707
*really* easy to use.
2709
Support for stdout was removed.
2711
A few new methods added.
2713
Charmap is now incorporated into ConfigObj.
2716
2004/03/14 - Version 2.0.0 beta
2717
-------------------------------
2719
Re-written it to subclass dict. My first forays into inheritance and operator
2722
The config object now behaves like a dictionary.
2724
I've completely broken the interface, but I don't think anyone was really
2727
This new version is much more 'classy'. {sm;:wink:}
2729
It will also read straight from/to a filename and completely parse a config
2730
file without you *having* to supply a config spec.
2732
Uses listparse, so can handle nested list items as values.
2734
No longer has getval and setval methods: use normal dictionary methods, or add
2738
2004/01/29 - Version 1.0.5
2739
--------------------------
2741
Version 1.0.5 has a couple of bugfixes as well as a couple of useful additions
2742
over previous versions.
2744
Since 1.0.0 the buildconfig function has been moved into this distribution,
2745
and the methods reset, verify, getval and setval have been added.
2747
A couple of bugs have been fixed.
2753
ConfigObj originated in a set of functions for reading config files in the
2754
`atlantibots <http://www.voidspace.org.uk/atlantibots/>`_ project. The original
2755
functions were written by Rob McNeur.
2764
.. [#] And if you discover any bugs, let us know. We'll fix them quickly.
2766
.. [#] If you specify a filename that doesn't exist, ConfigObj will assume you
2767
are creating a new one. See the *create_empty* and *file_error* options_.
2769
.. [#] They can be byte strings (*ordinary* strings) or Unicode.
2771
.. [#] Except we don't support the RFC822 style line continuations, nor ':' as
2774
.. [#] This is a change in ConfigObj 4.2.0. Note that ConfigObj doesn't call
2775
the seek method of any file like object you pass in. You may want to call
2776
``file_object.seek(0)`` yourself, first.
2778
.. [#] A side effect of this is that it enables you to copy a ConfigObj :
2784
# only copies members
2785
# not attributes/comments
2786
config2 = ConfigObj(config1)
2790
The order of values and sections will not be preserved, though.
2792
.. [#] Other than lists of strings.
2794
.. [#] The exception is if it detects a ``UTF16`` encoded file which it
2795
must decode before parsing.
2797
.. [#] The method signature shows that this method takes
2798
two arguments. The second is the section to be written. This is because the
2799
``write`` method is called recursively.
2801
.. [#] The dict method doesn't actually use the deepcopy mechanism. This means
2802
if you add nested lists (etc) to your ConfigObj, then the dictionary
2803
returned by dict may contain some references. For all *normal* ConfigObjs
2804
it will return a deepcopy.
2806
.. [#] Passing ``(section, key)`` rather than ``(value, key)`` allows you to
2807
change the value by setting ``section[key] = newval``. It also gives you
2808
access to the *rename* method of the section.
2810
.. [#] Minimum required version of *validate.py* 0.2.0 .
2815
Rendering this document with docutils also needs the
2816
textmacros module and the PySrc CSS stuff. See
2817
http://www.voidspace.org.uk/python/firedrop2/textmacros.shtml
2822
<div align="center">
2824
<a href="http://www.python.org">
2825
<img src="images/new_python.gif" width="100" height="103" border="0"
2826
alt="Powered by Python" />
2828
<a href="http://sourceforge.net">
2829
<img src="http://sourceforge.net/sflogo.php?group_id=123265&type=1" width="88" height="31" border="0" alt="SourceForge.net Logo" />
2831
<a href="http://www.opensource.org">
2832
<img src="images/osi-certified-120x100.gif" width="120" height="100" border="0"
2833
alt="Certified Open Source"/>
2837
<a href="http://www.voidspace.org.uk/python/index.shtml">
2838
<img src="images/pythonbanner.gif" width="468" height="60"
2839
alt="Python on Voidspace" border="0" />
2845
.. _listquote: http://www.voidspace.org.uk/python/modules.shtml#listquote
2846
.. _Michael Foord: http://www.voidspace.org.uk/python/weblog/index.shtml
2847
.. _Nicola Larosa: http://www.teknico.net
added
removed
bzrlib/util/configobj/docs/configobj.txt
