« back to all changes in this revision
Viewing changes to bzrlib/util/configobj/docs/configobj.txt
- browse files at revision 1941
- compare with another revision
- download diff
- download tarball
- view history from revision 1941
- Committer: Aaron Bentley
- Date: 2009-04-30 14:00:40 UTC
- mfrom: (1907.1.31 merge)
- Revision ID: aaron@aaronbentley.com-20090430140040-ataetqn5pyl4t376
Merge merge into current
- files removed:
- bzrlib/util/configobj/docs
- files modified:
- Makefile
added
removed
bzrlib/util/configobj/docs/configobj.txt
1
==================================
2
Reading and Writing Config Files
3
==================================
4
5
----------------------------------------
6
ConfigObj 4 Introduction and Reference
7
----------------------------------------
8
9
:Authors: Michael Foord, Nicola Larosa
10
:Version: ConfigObj 4.5.2
11
:Date: 2008/02/24
12
:Homepage: `ConfigObj Homepage`_
13
:Sourceforge: Sourceforge_
14
:Development: `SVN Repository`_
15
:License: `BSD License`_
16
:Support: `Mailing List`_
17
18
.. _Mailing List: http://lists.sourceforge.net/lists/listinfo/configobj-develop
19
.. _SVN Repository: http://svn.pythonutils.python-hosting.com
20
21
.. meta::
22
:description: ConfigObj - a Python module for easy reading and writing of
23
config files.
24
:keywords: python, script, module, config, configuration, data, persistence,
25
developer, configparser
26
27
28
.. contents:: ConfigObj Manual
29
.. sectnum::
30
31
32
Introduction
33
============
34
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 :
39
40
* Nested sections (subsections), to any level
41
* List values
42
* Multiple line values
43
* String interpolation (substitution)
44
* Integrated with a powerful validation system
45
46
- including automatic type checking/conversion
47
- repeated sections
48
- and allowing default values
49
50
* When writing out config files, ConfigObj preserves all comments and the order of members and sections
51
* Many useful methods and options for working with configuration files (like the 'reload' method)
52
* Full Unicode support
53
54
55
For support and bug reports please use the ConfigObj `Mailing List`_.
56
57
58
Downloading
59
===========
60
61
The current version is **4.5.2**, dated 24th February 2008. ConfigObj 4 is
62
now stable. We still expect to pick up a few bugs along the way though [#]_.
63
{sm;:-)}
64
65
You can get ConfigObj in the following ways :
66
67
Files
68
-----
69
70
* configobj.py_ from Voidspace
71
72
ConfigObj has no external dependencies. This file is sufficient to access
73
all the functionality except Validation_.
74
75
* configobj.zip_ from Voidspace
76
77
This also contains validate.py_ and `this document`_.
78
79
* The latest development version can be obtained from the `Subversion
80
Repository`_.
81
82
* validate.py_ from Voidspace
83
84
* You can also download *configobj.zip* from Sourceforge_
85
86
Documentation
87
-------------
88
89
*configobj.zip* also contains `this document`_.
90
91
* You can view `this document`_ online at the `ConfigObj Homepage`_.
92
93
94
Pythonutils
95
-----------
96
97
ConfigObj is also part of the Pythonutils_ set of modules. This contains
98
various other useful modules, and is required by many of the `Voidspace Python
99
Projects`_.
100
101
102
Development Version
103
-------------------
104
105
It is sometimes possible to get the latest *development version* of ConfigObj
106
from the `Subversion Repository <http://svn.pythonutils.python-hosting.com/trunk/pythonutils/>`_.
107
108
.. _configobj.py: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj.py
109
.. _configobj.zip: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj-4.5.2.zip
110
.. _validate.py: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=validate.py
111
.. _this document:
112
.. _configobj homepage: http://www.voidspace.org.uk/python/configobj.html
113
.. _Sourceforge: http://sourceforge.net/projects/configobj
114
.. _pythonutils: http://www.voidspace.org.uk/python/pythonutils.html
115
.. _Voidspace Python Projects: http://www.voidspace.org.uk/python/index.shtml
116
117
118
119
ConfigObj in the Real World
120
===========================
121
122
**ConfigObj** is widely used. Projects using it include:
123
124
* `Bazaar <http://bazaar-ng.org>`_.
125
126
Bazaar is a Python distributed {acro;VCS;Version Control System}.
127
ConfigObj is used to read ``bazaar.conf`` and ``branches.conf``.
128
129
* `Turbogears <http://www.turbogears.org/>`_
130
131
Turbogears is a web application framework.
132
133
* `Chandler <http://chandler.osafoundation.org/>`_
134
135
A Python and `wxPython <http://www.wxpython.org>`_
136
{acro;PIM;Personal Information Manager}, being developed by the
137
`OSAFoundation <http://www.osafoundation.org/>`_.
138
139
* `matplotlib <http://matplotlib.sourceforge.net/>`_
140
141
A 2D plotting library.
142
143
* `IPython <http://ipython.scipy.org/moin/>`_
144
145
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>`_.
146
147
* `Elisa - the Fluendo Mediacenter <http://elisa.fluendo.com/>`_
148
149
Elisa is an open source cross-platform media center solution designed to be simple for people not particularly familiar with computers.
150
151
152
Getting Started
153
===============
154
155
The outstanding feature of using ConfigObj is simplicity. Most functions can be
156
performed with single line commands.
157
158
159
Reading a Config File
160
---------------------
161
162
The normal way to read a config file, is to give ConfigObj the filename :
163
164
.. raw:: html
165
166
{+coloring}
167
168
from configobj import ConfigObj
169
config = ConfigObj(filename)
170
171
{-coloring}
172
173
You can also pass the config file in as a list of lines, or a ``StringIO``
174
instance, so it doesn't matter where your config data comes from.
175
176
You can then access members of your config file as a dictionary. Subsections
177
will also be dictionaries.
178
179
.. raw:: html
180
181
{+coloring}
182
183
from configobj import ConfigObj
184
config = ConfigObj(filename)
185
#
186
value1 = config['keyword1']
187
value2 = config['keyword2']
188
#
189
section1 = config['section1']
190
value3 = section1['keyword3']
191
value4 = section1['keyword4']
192
#
193
# you could also write
194
value3 = config['section1']['keyword3']
195
value4 = config['section1']['keyword4']
196
197
{-coloring}
198
199
200
Writing a Config File
201
---------------------
202
203
Creating a new config file is just as easy as reading one. You can specify a
204
filename when you create the ConfigObj, or do it later [#]_.
205
206
If you *don't* set a filename, then the ``write`` method will return a list of
207
lines instead of writing to file. See the write_ method for more details.
208
209
Here we show creating an empty ConfigObj, setting a filename and some values,
210
and then writing to file :
211
212
.. raw:: html
213
214
{+coloring}
215
216
from configobj import ConfigObj
217
config = ConfigObj()
218
config.filename = filename
219
#
220
config['keyword1'] = value1
221
config['keyword2'] = value2
222
#
223
config['section1'] = {}
224
config['section1']['keyword3'] = value3
225
config['section1']['keyword4'] = value4
226
#
227
section2 = {
228
'keyword5': value5,
229
'keyword6': value6,
230
'sub-section': {
231
'keyword7': value7
232
}
233
}
234
config['section2'] = section2
235
#
236
config['section3'] = {}
237
config['section3']['keyword 8'] = [value8, value9, value10]
238
config['section3']['keyword 9'] = [value11, value12, value13]
239
#
240
config.write()
241
242
{-coloring}
243
244
.. caution::
245
246
Keywords and section names can only be strings [#]_. Attempting to set
247
anything else will raise a ``ValueError``.
248
249
250
Config Files
251
------------
252
253
The config files that ConfigObj will read and write are based on the 'INI'
254
format. This means it will read and write files created for ``ConfigParser``
255
[#]_.
256
257
Keywords and values are separated by an ``'='``, and section markers are
258
between square brackets. Keywords, values, and section names can be surrounded
259
by single or double quotes. Indentation is not significant, but can be
260
preserved.
261
262
Subsections are indicated by repeating the square brackets in the section
263
marker. You nest levels by using more brackets.
264
265
You can have list values by separating items with a comma, and values spanning
266
multiple lines by using triple quotes (single or double).
267
268
For full details on all these see `the config file format`_. Here's an example
269
to illustrate : ::
270
271
# This is the 'initial_comment'
272
# Which may be several lines
273
keyword1 = value1
274
'keyword 2' = 'value 2'
275
276
[ "section 1" ]
277
# This comment goes with keyword 3
278
keyword 3 = value 3
279
'keyword 4' = value4, value 5, 'value 6'
280
281
[[ sub-section ]] # an inline comment
282
# sub-section is inside "section 1"
283
'keyword 5' = 'value 7'
284
'keyword 6' = '''A multiline value,
285
that spans more than one line :-)
286
The line breaks are included in the value.'''
287
288
[[[ sub-sub-section ]]]
289
# sub-sub-section is *in* 'sub-section'
290
# which is in 'section 1'
291
'keyword 7' = 'value 8'
292
293
[section 2] # an inline comment
294
keyword8 = "value 9"
295
keyword9 = value10 # an inline comment
296
# The 'final_comment'
297
# Which also may be several lines
298
299
300
ConfigObj specifications
301
========================
302
303
.. raw:: html
304
305
{+coloring}
306
307
config = ConfigObj(infile=None, options=None, **keywargs)
308
309
{-coloring}
310
311
312
infile
313
------
314
315
You don't need to specify an infile. If you omit it, an empty ConfigObj will be
316
created. ``infile`` *can* be :
317
318
* Nothing. In which case the ``filename`` attribute of your ConfigObj will be
319
``None``. You can set a filename at any time.
320
321
* A filename. What happens if the file doesn't already exist is determined by
322
the options_ ``file_error`` and ``create_empty``. The filename will be
323
preserved as the ``filename`` attribute. This can be changed at any time.
324
325
* A list of lines. Any trailing newlines will be removed from the lines. The
326
``filename`` attribute of your ConfigObj will be ``None``.
327
328
* A ``StringIO`` instance or file object, or any object with a ``read`` method.
329
The ``filename`` attribute of your ConfigObj will be ``None`` [#]_.
330
331
* A dictionary. You can initialise a ConfigObj from a dictionary [#]_. The
332
``filename`` attribute of your ConfigObj will be ``None``. All keys must be
333
strings. In this case, the order of values and sections is arbitrary.
334
335
336
options
337
-------
338
339
There are various options that control the way ConfigObj behaves. They can be
340
passed in as a dictionary of options, or as keyword arguments. Explicit keyword
341
arguments override the dictionary.
342
343
All of the options are available as attributes after the config file has been
344
parsed.
345
346
ConfigObj has the following options (with the default values shown) :
347
348
* 'raise_errors': ``False``
349
350
When parsing, it is possible that the config file will be badly formed. The
351
default is to parse the whole file and raise a single error at the end. You
352
can set ``raise_errors = True`` to have errors raised immediately. See the
353
exceptions_ section for more details.
354
355
Altering this value after initial parsing has no effect.
356
357
* 'list_values': ``True``
358
359
If ``True`` (the default) then list values are possible. If ``False``, the
360
values are not parsed for lists.
361
362
If ``list_values = False`` then single line values are not quoted or
363
unquoted when reading and writing.
364
365
Changing this value affects whether single line values will be quoted or
366
not when writing.
367
368
* 'create_empty': ``False``
369
370
If this value is ``True`` and the file specified by ``infile`` doesn't
371
exist, ConfigObj will create an empty file. This can be a useful test that
372
the filename makes sense: an impossible filename will cause an error.
373
374
Altering this value after initial parsing has no effect.
375
376
* 'file_error': ``False``
377
378
If this value is ``True`` and the file specified by ``infile`` doesn't
379
exist, ConfigObj will raise an ``IOError``.
380
381
Altering this value after initial parsing has no effect.
382
383
* 'interpolation': ``True``
384
385
Whether string interpolation is switched on or not. It is on (``True``) by
386
default.
387
388
You can set this attribute to change whether string interpolation is done
389
when values are fetched. See the `String Interpolation`_ section for more details.
390
391
* 'configspec': ``None``
392
393
If you want to use the validation system, you supply a configspec. This is
394
effectively a type of config file that specifies a check for each member.
395
This check can be used to do type conversion as well as check that the
396
value is within your required parameters.
397
398
You provide a configspec in the same way as you do the initial file: a
399
filename, or list of lines, etc. See the validation_ section for full
400
details on how to use the system.
401
402
When parsed, every section has a ``configspec`` with a dictionary of
403
configspec checks for *that section*.
404
405
* 'stringify': ``True``
406
407
If you use the validation scheme, it can do type checking *and* conversion
408
for you. This means you may want to set members to integers, or other
409
non-string values.
410
411
If 'stringify' is set to ``True`` (default) then non-string values will
412
be converted to strings when you write the config file. The validation_
413
process converts values from strings to the required type.
414
415
If 'stringify' is set to ``False``, attempting to set a member to a
416
non-string value [#]_ will raise a ``TypeError`` (no type conversion is
417
done by validation).
418
419
* 'indent_type': ``' '``
420
421
Indentation is not significant; it can however be present in the input and
422
output config. Any combination of tabs and spaces may be used: the string
423
will be repeated for each level of indentation. Typical values are: ``''``
424
(no indentation), ``' '`` (indentation with four spaces, the default),
425
``'\t'`` (indentation with one tab).
426
427
If this option is not specified, and the ConfigObj is initialised with a
428
dictionary, the indentation used in the output is the default one, that is,
429
four spaces.
430
431
If this option is not specified, and the ConfigObj is initialised with a
432
list of lines or a file, the indentation used in the first indented line is
433
selected and used in all output lines. If no input line is indented, no
434
output line will be either.
435
436
If this option *is* specified, the option value is used in the output
437
config, overriding the type of indentation in the input config (if any).
438
439
* 'encoding': ``None``
440
441
By default **ConfigObj** does not decode the file/strings you pass it into
442
Unicode [#]_. If you want your config file as Unicode (keys and members)
443
you need to provide an encoding to decode the file with. This encoding will
444
also be used to encode the config file when writing.
445
446
You can change the encoding attribute at any time.
447
448
Any characters in your strings that can't be encoded with the specified
449
encoding will raise a ``UnicodeEncodeError``.
450
451
.. note::
452
453
``UTF16`` encoded files will automatically be detected and decoded,
454
even if ``encoding`` is ``None``.
455
456
This is because it is a 16-bit encoding, and ConfigObj will mangle it
457
(split characters on byte boundaries) if it parses it without decoding.
458
459
* 'default_encoding': ``None``
460
461
When using the ``write`` method, **ConfigObj** uses the ``encoding``
462
attribute to encode the Unicode strings. If any members (or keys) have
463
been set as byte strings instead of Unicode, these must first be decoded
464
to Unicode before outputting in the specified encoding.
465
466
``default_encoding``, if specified, is the encoding used to decode byte
467
strings in the **ConfigObj** before writing. If this is ``None``, then
468
the Python default encoding (``sys.defaultencoding`` - usually ASCII) is
469
used.
470
471
For most Western European users, a value of ``latin-1`` is sensible.
472
473
``default_encoding`` is *only* used if an ``encoding`` is specified.
474
475
Any characters in byte-strings that can't be decoded using the
476
``default_encoding`` will raise a ``UnicodeDecodeError``.
477
478
* 'unrepr': ``False``
479
480
The ``unrepr`` option reads and writes files in a different mode. This
481
allows you to store and retrieve the basic Python data-types using config
482
files.
483
484
This uses Python syntax for lists and quoting. See `unrepr mode`_ for the
485
full details.
486
487
* 'write_empty_values': ``False``
488
489
If ``write_empty_values`` is ``True``, empty strings are written as
490
empty values. See `Empty Values`_ for more details.
491
492
493
Methods
494
-------
495
496
The ConfigObj is a subclass of an object called ``Section``, which is itself a
497
subclass of ``dict``, the builtin dictionary type. This means it also has
498
**all** the normal dictionary methods.
499
500
In addition, the following `Section Methods`_ may be useful :
501
502
* 'restore_default'
503
* 'restore_defaults'
504
* 'walk'
505
* 'merge'
506
* 'dict'
507
* 'as_bool'
508
* 'as_float'
509
* 'as_int'
510
511
Read about Sections_ for details of all the methods.
512
513
.. hint::
514
515
The *merge* method of sections is a recursive update.
516
517
You can use this to merge sections, or even whole ConfigObjs, into each
518
other.
519
520
You would typically use this to create a default ConfigObj and then merge
521
in user settings. This way users only need to specify values that are
522
different from the default. You can use configspecs and validation to
523
achieve the same thing of course.
524
525
526
The public methods available on ConfigObj are :
527
528
* 'write'
529
* 'validate'
530
* 'reset'
531
* 'reload'
532
533
534
write
535
~~~~~
536
537
::
538
539
write(file_object=None)
540
541
This method writes the current ConfigObj and takes a single, optional argument
542
[#]_.
543
544
If you pass in a file like object to the ``write`` method, the config file will
545
be written to this. (The only method of this object that is used is its
546
``write`` method, so a ``StringIO`` instance, or any other file like object
547
will work.)
548
549
Otherwise, the behaviour of this method depends on the ``filename`` attribute
550
of the ConfigObj.
551
552
``filename``
553
ConfigObj will write the configuration to the file specified.
554
555
``None``
556
``write`` returns a list of lines. (Not ``'\n'`` terminated)
557
558
First the 'initial_comment' is written, then the config file, followed by the
559
'final_comment'. Comment lines and inline comments are written with each
560
key/value.
561
562
563
validate
564
~~~~~~~~
565
566
::
567
568
validate(validator, preserve_errors=False, copy=False)
569
570
.. raw:: html
571
572
{+coloring}
573
574
# filename is the config file
575
# filename2 is the configspec
576
# (which could also be hardcoded into your program)
577
config = ConfigObj(filename, configspec=filename2)
578
#
579
from validate import Validator
580
val = Validator()
581
test = config.validate(val)
582
if test == True:
583
print 'Succeeded.'
584
{-coloring}
585
586
The validate method uses the `validate
587
<http://www.voidspace.org.uk/python/validate.html>`__ module to do the
588
validation.
589
590
This method validates the ConfigObj against the configspec. By doing type
591
conversion as well it can abstract away the config file altogether and present
592
the config *data* to your application (in the types it expects it to be).
593
594
If the ``configspec`` attribute of the ConfigObj is ``None``, it raises a
595
``ValueError``.
596
597
If the stringify_ attribute is set, this process will convert values to the
598
type defined in the configspec.
599
600
The validate method uses checks specified in the configspec and defined in the
601
``Validator`` object. It is very easy to extend.
602
603
The configspec looks like the config file, but instead of the value, you
604
specify the check (and any default value). See the validation_ section for
605
details.
606
607
.. hint::
608
609
The system of configspecs can seem confusing at first, but is actually
610
quite simple and powerful. For a concrete example of how to use it, you may
611
find this blog entry helpful :
612
`Transforming Values with ConfigObj <http://www.voidspace.org.uk/python/weblog/arch_d7_2006_03_04.shtml#e257>`_.
613
614
615
The ``copy`` parameter fills in missing values from the configspec (default
616
values), *without* marking the values as defaults. It also causes comments to
617
be copied from the configspec into the config file. This allows you to use a
618
configspec to create default config files. (Normally default values aren't
619
written out by the ``write`` method.)
620
621
As of ConfigObj 4.3.0 you can also pass in a ConfigObj instance as your
622
configspec. This is especially useful if you need to specify the encoding of
623
your configspec file. When you read your configspec file, you *must* specify
624
``list_values=False``.
625
626
.. raw:: html
627
628
{+coloring}
629
from configobj import ConfigObj
630
configspec = ConfigObj(configspecfilename, encoding='UTF8',
631
list_values=False)
632
config = ConfigObj(filename, configspec=configspec)
633
{-coloring}
634
635
636
Return Value
637
############
638
639
By default, the validate method either returns ``True`` (everything passed)
640
or a dictionary of ``True``/``False`` representing pass/fail. The dictionary
641
follows the structure of the ConfigObj.
642
643
If a whole section passes then it is replaced with the value ``True``. If a
644
whole section fails, then it is replaced with the value ``False``.
645
646
If a value is missing, and there is no default in the check, then the check
647
automatically fails.
648
649
The ``validate`` method takes an optional keyword argument ``preserve_errors``.
650
If you set this to ``True``, instead of getting ``False`` for failed checks you
651
get the actual error object from the **validate** module. This usually contains
652
useful information about why the check failed.
653
654
See the `flatten_errors`_ function for how to turn your results dictionary into
655
a useful list of error messages.
656
657
Even if ``preserve_errors`` is ``True``, missing keys or sections will still be
658
represented by a ``False`` in the results dictionary.
659
660
661
Mentioning Default Values
662
#########################
663
664
In the check in your configspec, you can specify a default to be used - by
665
using the ``default`` keyword. E.g. ::
666
667
key1 = integer(0, 30, default=15)
668
key2 = integer(default=15)
669
key3 = boolean(default=True)
670
key4 = option('Hello', 'Goodbye', 'Not Today', default='Not Today')
671
672
If the configspec check supplies a default and the value is missing in the
673
config, then the default will be set in your ConfigObj. (It is still passed to
674
the ``Validator`` so that type conversion can be done: this means the default
675
value must still pass the check.)
676
677
ConfigObj keeps a record of which values come from defaults, using the
678
``defaults`` attribute of sections_. Any key in this list isn't written out by
679
the ``write`` method. If a key is set from outside (even to the same value)
680
then it is removed from the ``defaults`` list.
681
682
.. note:
683
684
Even if all the keys in a section are in the defaults list, the section
685
marker is still written out.
686
687
There is additionally a special case default value of ``None``. If you set the
688
default value to ``None`` and the value is missing, the value will always be
689
set to ``None``. As the other checks don't return ``None`` (unless you
690
implement your own that do), you can tell that this value came from a default
691
value (and was missing from the config file). It allows an easy way of
692
implementing optional values. Simply check (and ignore) members that are set
693
to ``None``.
694
695
.. note::
696
697
If stringify_ is ``False`` then ``default=None`` returns ``''`` instead of
698
``None``. This is because setting a value to a non-string raises an error
699
if stringify is unset.
700
701
The default value can be a list. See `List Values`_ for the way to do this.
702
703
Writing invalid default values is a *guaranteed* way of confusing your users.
704
Default values **must** pass the check.
705
706
707
Mentioning Repeated Sections
708
############################
709
710
In the configspec it is possible to cause *every* sub-section in a section to
711
be validated using the same configspec. You do this with a section in the
712
configspec called ``__many__``. Every sub-section in that section has the
713
``__many__`` configspec applied to it (without you having to explicitly name
714
them in advance).
715
716
If you define a ``__many__`` type section it must the only sub-section in that
717
section. Having a ``__many__`` *and* other sub-sections defined in the same
718
section will raise a ``RepeatSectionError``.
719
720
Your ``__many__`` section can have nested subsections, which can also include
721
``__many__`` type sections.
722
723
See `Repeated Sections`_ for examples.
724
725
726
Mentioning SimpleVal
727
####################
728
729
If you just want to check if all members are present, then you can use the
730
``SimpleVal`` object that comes with ConfigObj. It only fails members if they
731
are missing.
732
733
Write a configspec that has all the members you want to check for, but set
734
every section to ``''``.
735
736
.. raw:: html
737
738
{+coloring}
739
740
val = SimpleVal()
741
test = config.validate(val)
742
if test is True:
743
print 'Succeeded.'
744
745
{-coloring}
746
747
748
Mentioning copy Mode
749
####################
750
751
As discussed in `Mentioning Default Values`_, you can use a configspec to
752
supply default values. These are marked in the ConfigObj instance as defaults,
753
and *not* written out by the ``write`` mode. This means that your users only
754
need to supply values that are different from the defaults.
755
756
This can be inconvenient if you *do* want to write out the default values,
757
for example to write out a default config file.
758
759
If you set ``copy=True`` when you call validate, then no values are marked as
760
defaults. In addition, all comments from the configspec are copied into
761
your ConfigObj instance. You can then call ``write`` to create your config
762
file.
763
764
There is a limitation with this. In order to allow `String Interpolation`_ to work
765
within configspecs, ``DEFAULT`` sections are not processed by
766
validation; even in copy mode.
767
768
769
reload
770
~~~~~~
771
772
If a ConfigObj instance was loaded from the filesystem, then this method will reload it. It
773
will also reuse any configspec you supplied at instantiation (including reloading it from
774
the filesystem if you passed it in as a filename).
775
776
If the ConfigObj does not have a filename attribute pointing to a file, then a ``ReloadError``
777
will be raised.
778
779
780
reset
781
~~~~~
782
783
This method takes no arguments and doesn't return anything. It restores a ConfigObj
784
instance to a freshly created state.
785
786
787
Attributes
788
----------
789
790
A ConfigObj has the following attributes :
791
792
* indent_type
793
* interpolate
794
* stringify
795
* BOM
796
* initial_comment
797
* final_comment
798
* list_values
799
* encoding
800
* default_encoding
801
* unrepr
802
* write_empty_values
803
* newlines
804
805
.. note::
806
807
This doesn't include *comments*, *inline_comments*, *defaults*, or
808
*configspec*. These are actually attributes of Sections_.
809
810
It also has the following attributes as a result of parsing. They correspond to
811
options_ when the ConfigObj was created, but changing them has no effect.
812
813
* raise_errors
814
* create_empty
815
* file_error
816
817
818
interpolation
819
~~~~~~~~~~~~~
820
821
ConfigObj can perform string interpolation in a *similar* way to
822
``ConfigParser``. See the `String Interpolation`_ section for full details.
823
824
If ``interpolation`` is set to ``False``, then interpolation is *not* done when
825
you fetch values.
826
827
828
stringify
829
~~~~~~~~~
830
831
If this attribute is set (``True``) then the validate_ method changes the
832
values in the ConfigObj. These are turned back into strings when write_ is
833
called.
834
835
If stringify is unset (``False``) then attempting to set a value to a non
836
string (or a list of strings) will raise a ``TypeError``.
837
838
839
BOM
840
~~~
841
842
If the initial config file *started* with the UTF8 Unicode signature (known
843
slightly incorrectly as the {acro;BOM;Byte Order Mark}), or the UTF16 BOM, then
844
this attribute is set to ``True``. Otherwise it is ``False``.
845
846
If it is set to ``True`` when ``write`` is called then, if ``encoding`` is set
847
to ``None`` *or* to ``utf_8`` (and variants) a UTF BOM will be written.
848
849
For UTF16 encodings, a BOM is *always* written.
850
851
852
initial_comment
853
~~~~~~~~~~~~~~~
854
855
This is a list of lines. If the ConfigObj is created from an existing file, it
856
will contain any lines of comments before the start of the members.
857
858
If you create a new ConfigObj, this will be an empty list.
859
860
The write method puts these lines before it starts writing out the members.
861
862
863
final_comment
864
~~~~~~~~~~~~~
865
866
This is a list of lines. If the ConfigObj is created from an existing file, it
867
will contain any lines of comments after the last member.
868
869
If you create a new ConfigObj, this will be an empty list.
870
871
The ``write`` method puts these lines after it finishes writing out the
872
members.
873
874
875
list_values
876
~~~~~~~~~~~
877
878
This attribute is ``True`` or ``False``. If set to ``False`` then values are
879
not parsed for list values. In addition single line values are not unquoted.
880
881
This allows you to do your own parsing of values. It exists primarily to
882
support the reading of the configspec_ - but has other use cases.
883
884
For example you could use the ``LineParser`` from the
885
`listquote module <http://www.voidspace.org.uk/python/listquote.html#lineparser>`_
886
to read values for nested lists.
887
888
Single line values aren't quoted when writing - but multiline values are
889
handled as normal.
890
891
.. caution::
892
893
Because values aren't quoted, leading or trailing whitespace can be
894
lost.
895
896
This behaviour was changed in version 4.0.1.
897
898
Prior to this, single line values might have been quoted; even with
899
``list_values=False``. This means that files written by **ConfigObj**
900
*could* now be incompatible - and need the quotes removing by hand.
901
902
903
encoding
904
~~~~~~~~
905
906
This is the encoding used to encode the output, when you call ``write``. It
907
must be a valid encoding `recognised by Python <http://docs.python.org/lib/standard-encodings.html>`_.
908
909
If this value is ``None`` then no encoding is done when ``write`` is called.
910
911
912
default_encoding
913
~~~~~~~~~~~~~~~~
914
915
If encoding is set, any byte-strings in your ConfigObj instance (keys or
916
members) will first be decoded to Unicode using the encoding specified by the
917
``default_encoding`` attribute. This ensures that the output is in the encoding
918
specified.
919
920
If this value is ``None`` then ``sys.defaultencoding`` is used instead.
921
922
923
unrepr
924
~~~~~~
925
926
Another boolean value. If this is set, then ``repr(value)`` is used to write
927
values. This writes values in a slightly different way to the normal ConfigObj
928
file syntax.
929
930
This preserves basic Python data-types when read back in. See `unrepr mode`_
931
for more details.
932
933
934
write_empty_values
935
~~~~~~~~~~~~~~~~~~
936
937
Also boolean. If set, values that are an empty string (``''``) are written as
938
empty values. See `Empty Values`_ for more details.
939
940
941
newlines
942
~~~~~~~~
943
944
When a config file is read, ConfigObj records the type of newline separators in the
945
file and uses this separator when writing. It defaults to ``None``, and ConfigObj
946
uses the system default (``os.sep``) if write is called without newlines having
947
been set.
948
949
950
The Config File Format
951
======================
952
953
You saw an example config file in the `Config Files`_ section. Here is a fuller
954
specification of the config files used and created by ConfigObj.
955
956
The basic pattern for keywords is : ::
957
958
# comment line
959
# comment line
960
keyword = value # inline comment
961
962
Both keyword and value can optionally be surrounded in quotes. The equals sign
963
is the only valid divider.
964
965
Values can have comments on the lines above them, and an inline comment after
966
them. This, of course, is optional. See the comments_ section for details.
967
968
If a keyword or value starts or ends with whitespace, or contains a quote mark
969
or comma, then it should be surrounded by quotes. Quotes are not necessary if
970
whitespace is surrounded by non-whitespace.
971
972
Values can also be lists. Lists are comma separated. You indicate a single
973
member list by a trailing comma. An empty list is shown by a single comma : ::
974
975
keyword1 = value1, value2, value3
976
keyword2 = value1, # a single member list
977
keyword3 = , # an empty list
978
979
Values that contain line breaks (multi-line values) can be surrounded by triple
980
quotes. These can also be used if a value contains both types of quotes. List
981
members cannot be surrounded by triple quotes : ::
982
983
keyword1 = ''' A multi line value
984
on several
985
lines''' # with a comment
986
keyword2 = '''I won't be "afraid".'''
987
#
988
keyword3 = """ A multi line value
989
on several
990
lines""" # with a comment
991
keyword4 = """I won't be "afraid"."""
992
993
.. warning::
994
995
There is no way of safely quoting values that contain both types of triple
996
quotes.
997
998
A line that starts with a '#', possibly preceded by whitespace, is a comment.
999
1000
New sections are indicated by a section marker line. That is the section name
1001
in square brackets. Whitespace around the section name is ignored. The name can
1002
be quoted with single or double quotes. The marker can have comments before it
1003
and an inline comment after it : ::
1004
1005
# The First Section
1006
[ section name 1 ] # first section
1007
keyword1 = value1
1008
1009
# The Second Section
1010
[ "section name 2" ] # second section
1011
keyword2 = value2
1012
1013
Any subsections (sections that are *inside* the current section) are
1014
designated by repeating the square brackets before and after the section name.
1015
The number of square brackets represents the nesting level of the sub-section.
1016
Square brackets may be separated by whitespace; such whitespace, however, will
1017
not be present in the output config written by the ``write`` method.
1018
1019
Indentation is not significant, but can be preserved. See the description of
1020
the ``indent_type`` option, in the `ConfigObj specifications`_ chapter, for the
1021
details.
1022
1023
A *NestingError* will be raised if the number of the opening and the closing
1024
brackets in a section marker is not the same, or if a sub-section's nesting
1025
level is greater than the nesting level of it parent plus one.
1026
1027
In the outer section, single values can only appear before any sub-section.
1028
Otherwise they will belong to the sub-section immediately before them. ::
1029
1030
# initial comment
1031
keyword1 = value1
1032
keyword2 = value2
1033
1034
[section 1]
1035
keyword1 = value1
1036
keyword2 = value2
1037
1038
[[sub-section]]
1039
# this is in section 1
1040
keyword1 = value1
1041
keyword2 = value2
1042
1043
[[[nested section]]]
1044
# this is in sub section
1045
keyword1 = value1
1046
keyword2 = value2
1047
1048
[[sub-section2]]
1049
# this is in section 1 again
1050
keyword1 = value1
1051
keyword2 = value2
1052
1053
[[sub-section3]]
1054
# this is also in section 1, indentation is misleading here
1055
keyword1 = value1
1056
keyword2 = value2
1057
1058
# final comment
1059
1060
When parsed, the above config file produces the following data structure :
1061
1062
.. raw:: html
1063
1064
{+coloring}
1065
1066
ConfigObj({
1067
'keyword1': 'value1',
1068
'keyword2': 'value2',
1069
'section 1': {
1070
'keyword1': 'value1',
1071
'keyword2': 'value2',
1072
'sub-section': {
1073
'keyword1': 'value1',
1074
'keyword2': 'value2',
1075
'nested section': {
1076
'keyword1': 'value1',
1077
'keyword2': 'value2',
1078
},
1079
},
1080
'sub-section2': {
1081
'keyword1': 'value1',
1082
'keyword2': 'value2',
1083
},
1084
'sub-section3': {
1085
'keyword1': 'value1',
1086
'keyword2': 'value2',
1087
},
1088
},
1089
})
1090
1091
{-coloring}
1092
1093
Sections are ordered: note how the structure of the resulting ConfigObj is in
1094
the same order as the original file.
1095
1096
.. note::
1097
1098
In ConfigObj 4.3.0 *empty values* became valid syntax. They are read as the
1099
empty string. There is also an option/attribute (``write_empty_values``) to
1100
allow the writing of these.
1101
1102
This is mainly to support 'legacy' config files, written from other
1103
applications. This is documented under `Empty Values`_.
1104
1105
`unrepr mode`_ introduces *another* syntax variation, used for storing
1106
basic Python datatypes in config files. {sm;:-)}
1107
1108
1109
Sections
1110
========
1111
1112
Every section in a ConfigObj has certain properties. The ConfigObj itself also
1113
has these properties, because it too is a section (sometimes called the *root
1114
section*).
1115
1116
``Section`` is a subclass of the standard new-class dictionary, therefore it
1117
has **all** the methods of a normal dictionary. This means you can ``update``
1118
and ``clear`` sections.
1119
1120
.. note::
1121
1122
You create a new section by assigning a member to be a dictionary.
1123
1124
The new ``Section`` is created *from* the dictionary, but isn't the same
1125
thing as the dictionary. (So references to the dictionary you use to create
1126
the section *aren't* references to the new section).
1127
1128
Note the following.
1129
1130
.. raw:: html
1131
1132
{+coloring}
1133
1134
config = ConfigObj()
1135
vals = {'key1': 'value 1',
1136
'key2': 'value 2'
1137
}
1138
config['vals'] = vals
1139
config['vals'] == vals
1140
True
1141
config['vals'] is vals
1142
False
1143
1144
{-coloring}
1145
1146
If you now change ``vals``, the changes won't be reflected in ``config['vals']``.
1147
1148
A section is ordered, following its ``scalars`` and ``sections``
1149
attributes documented below. This means that the following dictionary
1150
attributes return their results in order.
1151
1152
* '__iter__'
1153
1154
More commonly known as ``for member in section:``.
1155
1156
* '__repr__' and '__str__'
1157
1158
Any time you print or display the ConfigObj.
1159
1160
* 'items'
1161
1162
* 'iteritems'
1163
1164
* 'iterkeys'
1165
1166
* 'itervalues'
1167
1168
* 'keys'
1169
1170
* 'popitem'
1171
1172
* 'values'
1173
1174
1175
Section Attributes
1176
------------------
1177
1178
* main
1179
1180
A reference to the main ConfigObj.
1181
1182
* parent
1183
1184
A reference to the 'parent' section, the section that this section is a
1185
member of.
1186
1187
On the ConfigObj this attribute is a reference to itself. You can use this
1188
to walk up the sections, stopping when ``section.parent is section``.
1189
1190
* depth
1191
1192
The nesting level of the current section.
1193
1194
If you create a new ConfigObj and add sections, 1 will be added to the
1195
depth level between sections.
1196
1197
* defaults
1198
1199
This attribute is a list of scalars that came from default values. Values
1200
that came from defaults aren't written out by the ``write`` method.
1201
Setting any of these values in the section removes them from the defaults
1202
list.
1203
1204
* default_values
1205
1206
This attribute is a dictionary mapping keys to the default values for the
1207
keys. By default it is an empty dictionary and is populated when you
1208
validate the ConfigObj.
1209
1210
* scalars, sections
1211
1212
These attributes are normal lists, representing the order that members,
1213
single values and subsections appear in the section. The order will either
1214
be the order of the original config file, *or* the order that you added
1215
members.
1216
1217
The order of members in this lists is the order that ``write`` creates in
1218
the config file. The ``scalars`` list is output before the ``sections``
1219
list.
1220
1221
Adding or removing members also alters these lists. You can manipulate the
1222
lists directly to alter the order of members.
1223
1224
.. warning::
1225
1226
If you alter the ``scalars``, ``sections``, or ``defaults`` attributes
1227
so that they no longer reflect the contents of the section, you will
1228
break your ConfigObj.
1229
1230
See also the ``rename`` method.
1231
1232
* comments
1233
1234
This is a dictionary of comments associated with each member. Each entry is
1235
a list of lines. These lines are written out before the member.
1236
1237
* inline_comments
1238
1239
This is *another* dictionary of comments associated with each member. Each
1240
entry is a string that is put inline with the member.
1241
1242
* configspec
1243
1244
The configspec attribute is a dictionary mapping scalars to *checks*. A
1245
check defines the expected type and possibly the allowed values for a
1246
member.
1247
1248
The configspec has the same format as a config file, but instead of values
1249
it has a specification for the value (which may include a default value).
1250
The validate_ method uses it to check the config file makes sense. If a
1251
configspec is passed in when the ConfigObj is created, then it is parsed
1252
and broken up to become the ``configspec`` attribute of each section.
1253
1254
If you didn't pass in a configspec, this attribute will be ``None`` on the
1255
root section (the main ConfigObj).
1256
1257
You can set the configspec attribute directly on a section.
1258
1259
See the validation_ section for full details of how to write configspecs.
1260
1261
1262
Section Methods
1263
---------------
1264
1265
* **dict**
1266
1267
This method takes no arguments. It returns a deep copy of the section as a
1268
dictionary. All subsections will also be dictionaries, and list values will
1269
be copies, rather than references to the original [#]_.
1270
1271
* **rename**
1272
1273
``rename(oldkey, newkey)``
1274
1275
This method renames a key, without affecting its position in the sequence.
1276
1277
It is mainly implemented for the ``encode`` and ``decode`` methods, which
1278
provide some Unicode support.
1279
1280
* **merge**
1281
1282
``merge(indict)``
1283
1284
This method is a *recursive update* method. It allows you to merge two
1285
config files together.
1286
1287
You would typically use this to create a default ConfigObj and then merge
1288
in user settings. This way users only need to specify values that are
1289
different from the default.
1290
1291
For example :
1292
1293
.. raw:: html
1294
1295
{+coloring}
1296
1297
# def_cfg contains your default config settings
1298
# user_cfg contains the user settings
1299
cfg = ConfigObj(def_cfg)
1300
usr = ConfigObj(user_cfg)
1301
#
1302
cfg.merge(usr)
1303
1304
"""
1305
cfg now contains a combination of the default settings and the user
1306
settings.
1307
1308
The user settings will have overwritten any of the default ones.
1309
"""
1310
1311
{-coloring}
1312
1313
* **walk**
1314
1315
This method can be used to transform values and names. See `walking a
1316
section`_ for examples and explanation.
1317
1318
* **decode**
1319
1320
``decode(encoding)``
1321
1322
This method decodes names and values into Unicode objects, using the
1323
supplied encoding.
1324
1325
* **encode**
1326
1327
``encode(encoding)``
1328
1329
This method is the opposite of ``decode`` {sm;:!:}.
1330
1331
It encodes names and values using the supplied encoding. If any of your
1332
names/values are strings rather than Unicode, Python will have to do an
1333
implicit decode first. (This method uses ``sys.defaultencoding`` for
1334
implicit decodes.)
1335
1336
* **as_bool**
1337
1338
``as_bool(key)``
1339
1340
Returns ``True`` if the key contains a string that represents ``True``, or
1341
is the ``True`` object.
1342
1343
Returns ``False`` if the key contains a string that represents ``False``,
1344
or is the ``False`` object.
1345
1346
Raises a ``ValueError`` if the key contains anything else.
1347
1348
Strings that represent ``True`` are (not case sensitive) : ::
1349
1350
true, yes, on, 1
1351
1352
Strings that represent ``False`` are : ::
1353
1354
false, no, off, 0
1355
1356
.. note::
1357
1358
In ConfigObj 4.1.0, this method was called ``istrue``. That method is
1359
now deprecated and will issue a warning when used. It will go away
1360
in a future release.
1361
1362
* **as_int**
1363
1364
``as_int(key)``
1365
1366
This returns the value contained in the specified key as an integer.
1367
1368
It raises a ``ValueError`` if the conversion can't be done.
1369
1370
* **as_float**
1371
1372
``as_float(key)``
1373
1374
This returns the value contained in the specified key as a float.
1375
1376
It raises a ``ValueError`` if the conversion can't be done.
1377
1378
* **restore_default**
1379
1380
``restore_default(key)``
1381
1382
Restore (and return) the default value for the specified key.
1383
1384
This method will only work for a ConfigObj that was created
1385
with a configspec and has been validated.
1386
1387
If there is no default value for this key, ``KeyError`` is raised.
1388
1389
* **restore_defaults**
1390
1391
``restore_defaults()``
1392
1393
Recursively restore default values to all members
1394
that have them.
1395
1396
This method will only work for a ConfigObj that was created
1397
with a configspec and has been validated.
1398
1399
It doesn't delete or modify entries without default values.
1400
1401
1402
Walking a Section
1403
-----------------
1404
1405
.. note::
1406
1407
The walk method allows you to call a function on every member/name.
1408
1409
.. raw:: html
1410
1411
{+coloring}
1412
1413
walk(function, raise_errors=True,
1414
call_on_sections=False, **keywargs):
1415
1416
{-coloring}
1417
1418
``walk`` is a method of the ``Section`` object. This means it is also a method
1419
of ConfigObj.
1420
1421
It walks through every member and calls a function on the keyword and value. It
1422
walks recursively through subsections.
1423
1424
It returns a dictionary of all the computed values.
1425
1426
If the function raises an exception, the default is to propagate the error, and
1427
stop. If ``raise_errors=False`` then it sets the return value for that keyword
1428
to ``False`` instead, and continues. This is similar to the way validation_
1429
works.
1430
1431
Your function receives the arguments ``(section, key)``. The current value is
1432
then ``section[key]`` [#]_. Any unrecognised keyword arguments you pass to
1433
walk, are passed on to the function.
1434
1435
Normally ``walk`` just recurses into subsections. If you are transforming (or
1436
checking) names as well as values, then you want to be able to change the names
1437
of sections. In this case set ``call_on_sections`` to ``True``. Now, on
1438
encountering a sub-section, *first* the function is called for the *whole*
1439
sub-section, and *then* it recurses into it's members. This means your function
1440
must be able to handle receiving dictionaries as well as strings and lists.
1441
1442
If you are using the return value from ``walk`` *and* ``call_on_sections``,
1443
note that walk discards the return value when it calls your function.
1444
1445
.. caution::
1446
1447
You can use ``walk`` to transform the names of members of a section
1448
but you mustn't add or delete members.
1449
1450
1451
Examples
1452
--------
1453
1454
Examples that use the walk method are the ``encode`` and ``decode`` methods.
1455
They both define a function and pass it to walk. Because these functions
1456
transform names as well as values (from byte strings to Unicode) they set
1457
``call_on_sections=True``.
1458
1459
To see how they do it, *read the source Luke* {sm;:cool:}.
1460
1461
You can use this for transforming all values in your ConfigObj. For example
1462
you might like the nested lists from ConfigObj 3. This was provided by the
1463
listquote_ module. You could switch off the parsing for list values
1464
(``list_values=False``) and use listquote to parse every value.
1465
1466
Another thing you might want to do is use the Python escape codes in your
1467
values. You might be *used* to using ``\n`` for line feed and ``\t`` for tab.
1468
Obviously we'd need to decode strings that come from the config file (using the
1469
escape codes). Before writing out we'll need to put the escape codes back in
1470
encode.
1471
1472
As an example we'll write a function to use with walk, that encodes or decodes
1473
values using the ``string-escape`` codec.
1474
1475
The function has to take each value and set the new value. As a bonus we'll
1476
create one function that will do decode *or* encode depending on a keyword
1477
argument.
1478
1479
We don't want to work with section names, we're only transforming values, so
1480
we can leave ``call_on_sections`` as ``False``. This means the two datatypes we
1481
have to handle are strings and lists, we can ignore everything else. (We'll
1482
treat tuples as lists as well).
1483
1484
We're not using the return values, so it doesn't need to return anything, just
1485
change the values if appropriate.
1486
1487
.. raw:: html
1488
1489
{+coloring}
1490
1491
def string_escape(section, key, encode=False):
1492
"""
1493
A function to encode or decode using the 'string-escape' codec.
1494
To be passed to the walk method of a ConfigObj.
1495
By default it decodes.
1496
To encode, pass in the keyword argument ``encode=True``.
1497
"""
1498
val = section[key]
1499
# is it a type we can work with
1500
# NOTE: for platforms where Python > 2.2
1501
# you can use basestring instead of (str, unicode)
1502
if not isinstance(val, (str, unicode, list, tuple)):
1503
# no !
1504
return
1505
elif isinstance(val, (str, unicode)):
1506
# it's a string !
1507
if not encode:
1508
section[key] = val.decode('string-escape')
1509
else:
1510
section[key] = val.encode('string-escape')
1511
else:
1512
# it must be a list or tuple!
1513
# we'll be lazy and create a new list
1514
newval = []
1515
# we'll check every member of the list
1516
for entry in val:
1517
if isinstance(entry, (str, unicode)):
1518
if not encode:
1519
newval.append(entry.decode('string-escape'))
1520
else:
1521
newval.append(entry.encode('string-escape'))
1522
else:
1523
newval.append(entry)
1524
# done !
1525
section[key] = newval
1526
1527
# assume we have a ConfigObj called ``config``
1528
#
1529
# To decode
1530
config.walk(string_escape)
1531
#
1532
# To encode.
1533
# Because ``walk`` doesn't recognise the ``encode`` argument
1534
# it passes it to our function.
1535
config.walk(string_escape, encode=True)
1536
1537
{-coloring}
1538
1539
Here's a simple example of using ``walk`` to transform names and values. One
1540
usecase of this would be to create a *standard* config file with placeholders
1541
for section and keynames. You can then use walk to create new config files
1542
and change values and member names :
1543
1544
.. raw:: html
1545
1546
{+coloring}
1547
1548
# We use 'XXXX' as a placeholder
1549
config = '''
1550
XXXXkey1 = XXXXvalue1
1551
XXXXkey2 = XXXXvalue2
1552
XXXXkey3 = XXXXvalue3
1553
[XXXXsection1]
1554
XXXXkey1 = XXXXvalue1
1555
XXXXkey2 = XXXXvalue2
1556
XXXXkey3 = XXXXvalue3
1557
[XXXXsection2]
1558
XXXXkey1 = XXXXvalue1
1559
XXXXkey2 = XXXXvalue2
1560
XXXXkey3 = XXXXvalue3
1561
[[XXXXsection1]]
1562
XXXXkey1 = XXXXvalue1
1563
XXXXkey2 = XXXXvalue2
1564
XXXXkey3 = XXXXvalue3
1565
'''.splitlines()
1566
cfg = ConfigObj(config)
1567
#
1568
def transform(section, key):
1569
val = section[key]
1570
newkey = key.replace('XXXX', 'CLIENT1')
1571
section.rename(key, newkey)
1572
if isinstance(val, (tuple, list, dict)):
1573
pass
1574
else:
1575
val = val.replace('XXXX', 'CLIENT1')
1576
section[newkey] = val
1577
#
1578
cfg.walk(transform, call_on_sections=True)
1579
print cfg
1580
ConfigObj({'CLIENT1key1': 'CLIENT1value1', 'CLIENT1key2': 'CLIENT1value2',
1581
'CLIENT1key3': 'CLIENT1value3',
1582
'CLIENT1section1': {'CLIENT1key1': 'CLIENT1value1',
1583
'CLIENT1key2': 'CLIENT1value2', 'CLIENT1key3': 'CLIENT1value3'},
1584
'CLIENT1section2': {'CLIENT1key1': 'CLIENT1value1',
1585
'CLIENT1key2': 'CLIENT1value2', 'CLIENT1key3': 'CLIENT1value3',
1586
'CLIENT1section1': {'CLIENT1key1': 'CLIENT1value1',
1587
'CLIENT1key2': 'CLIENT1value2', 'CLIENT1key3': 'CLIENT1value3'}}})
1588
1589
{-coloring}
1590
1591
1592
Exceptions
1593
==========
1594
1595
There are several places where ConfigObj may raise exceptions (other than
1596
because of bugs).
1597
1598
1) If a configspec filename you pass in doesn't exist, or a config file
1599
filename doesn't exist *and* ``file_error=True``, an ``IOError`` will be
1600
raised.
1601
1602
2) If you try to set a non-string key, or a non string value when
1603
``stringify=False``, a ``TypeError`` will be raised.
1604
1605
3) A badly built config file will cause parsing errors.
1606
1607
4) A parsing error can also occur when reading a configspec.
1608
1609
5) In string interpolation you can specify a value that doesn't exist, or
1610
create circular references (recursion).
1611
1612
6) If you have a ``__many__`` repeated section with other section definitions
1613
(in a configspec), a ``RepeatSectionError`` will be raised.
1614
1615
Number 5 (which is actually two different types of exceptions) is documented
1616
in `String Interpolation`_.
1617
1618
Number 6 is explained in the validation_ section.
1619
1620
*This* section is about errors raised during parsing.
1621
1622
The base error class is ``ConfigObjError``. This is a subclass of
1623
``SyntaxError``, so you can trap for ``SyntaxError`` without needing to
1624
directly import any of the ConfigObj exceptions.
1625
1626
The following other exceptions are defined (all deriving from
1627
``ConfigObjError``) :
1628
1629
* ``NestingError``
1630
1631
This error indicates either a mismatch in the brackets in a section marker,
1632
or an excessive level of nesting.
1633
1634
* ``ParseError``
1635
1636
This error indicates that a line is badly written. It is neither a valid
1637
``key = value`` line, nor a valid section marker line, nor a comment line.
1638
1639
* ``DuplicateError``
1640
1641
The keyword or section specified already exists.
1642
1643
* ``ConfigspecError``
1644
1645
An error occurred whilst parsing a configspec.
1646
1647
* ``UnreprError``
1648
1649
An error occurred when parsing a value in `unrepr mode`_.
1650
1651
* ``ReloadError``
1652
1653
``reload`` was called on a ConfigObj instance that doesn't have a valid
1654
filename attribute.
1655
1656
When parsing a configspec, ConfigObj will stop on the first error it
1657
encounters. It will raise a ``ConfigspecError``. This will have an ``error``
1658
attribute, which is the actual error that was raised.
1659
1660
Behaviour when parsing a config file depends on the option ``raise_errors``.
1661
If ConfigObj encounters an error while parsing a config file:
1662
1663
If ``raise_errors=True`` then ConfigObj will raise the appropriate error
1664
and parsing will stop.
1665
1666
If ``raise_errors=False`` (the default) then parsing will continue to the
1667
end and *all* errors will be collected.
1668
1669
If ``raise_errors`` is False and multiple errors are found a ``ConfigObjError``
1670
is raised. The error raised has a ``config`` attribute, which is the parts of
1671
the ConfigObj that parsed successfully. It also has an attribute ``errors``,
1672
which is a list of *all* the errors raised. Each entry in the list is an
1673
instance of the appropriate error type. Each one has the following attributes
1674
(useful for delivering a sensible error message to your user) :
1675
1676
* ``line``: the original line that caused the error.
1677
1678
* ``line_number``: its number in the config file.
1679
1680
* ``message``: the error message that accompanied the error.
1681
1682
If only one error is found, then that error is re-raised. The error still has
1683
the ``config`` and ``errors`` attributes. This means that your error handling
1684
code can be the same whether one error is raised in parsing , or several.
1685
1686
It also means that in the most common case (a single error) a useful error
1687
message will be raised.
1688
1689
.. note::
1690
1691
One wrongly written line could break the basic structure of your config
1692
file. This could cause every line after it to flag an error, so having a
1693
list of all the lines that caused errors may not be as useful as it sounds.
1694
{sm;:-(}.
1695
1696
1697
Validation
1698
==========
1699
1700
.. hint::
1701
1702
The system of configspecs can seem confusing at first, but is actually
1703
quite simple and powerful. For a concrete example of how to use it, you may
1704
find this blog entry helpful :
1705
`Transforming Values with ConfigObj <http://www.voidspace.org.uk/python/weblog/arch_d7_2006_03_04.shtml#e257>`_.
1706
1707
Validation is done through a combination of the configspec_ and a ``Validator``
1708
object. For this you need *validate.py* [#]_. See downloading_ if you don't
1709
have a copy.
1710
1711
Validation can perform two different operations :
1712
1713
1) Check that a value meets a specification. For example, check that a value
1714
is an integer between one and six, or is a choice from a specific set of
1715
options.
1716
1717
2) It can convert the value into the type required. For example, if one of
1718
your values is a port number, validation will turn it into an integer for
1719
you.
1720
1721
So validation can act as a transparent layer between the datatypes of your
1722
application configuration (boolean, integers, floats, etc) and the text format
1723
of your config file.
1724
1725
1726
configspec
1727
----------
1728
1729
The ``validate`` method checks members against an entry in the configspec. Your
1730
configspec therefore resembles your config file, with a check for every member.
1731
1732
In order to perform validation you need a ``Validator`` object. This has
1733
several useful built-in check functions. You can also create your own custom
1734
functions and register them with your Validator object.
1735
1736
Each check is the name of one of these functions, including any parameters and
1737
keyword arguments. The configspecs look like function calls, and they map to
1738
function calls.
1739
1740
The basic datatypes that an un-extended Validator can test for are :
1741
1742
* boolean values (True and False)
1743
* integers (including minimum and maximum values)
1744
* floats (including min and max)
1745
* strings (including min and max length)
1746
* IP addresses (v4 only)
1747
1748
It can also handle lists of these types and restrict a value to being one from
1749
a set of options.
1750
1751
An example configspec is going to look something like : ::
1752
1753
port = integer(0, 100)
1754
user = string(max=25)
1755
mode = option('quiet', 'loud', 'silent')
1756
1757
You can specify default values, and also have the same configspec applied to
1758
several sections. This is called `repeated sections`_.
1759
1760
For full details on writing configspecs, please refer to the `validate.py
1761
documentation`_.
1762
1763
.. important::
1764
1765
Your configspec is read by ConfigObj in the same way as a config file.
1766
1767
That means you can do interpolation *within* your configspec.
1768
1769
In order to allow this, checks in the 'DEFAULT' section (of the root level
1770
of your configspec) are *not* used.
1771
1772
If you need to specify the encoding of your configspec, then you can pass in a
1773
ConfigObj instance as your configspec. When you read your configspec file, you
1774
*must* specify ``list_values=False``.
1775
1776
.. raw:: html
1777
1778
{+coloring}
1779
from configobj import ConfigObj
1780
configspec = ConfigObj(configspecfilename, encoding='UTF8',
1781
list_values=False)
1782
config = ConfigObj(filename, configspec=configspec)
1783
{-coloring}
1784
1785
.. _validate.py documentation: http://www.voidspace.org.uk/python/validate.html
1786
1787
1788
Type Conversion
1789
---------------
1790
1791
By default, validation does type conversion. This means that if you specify
1792
``integer`` as the check, then calling validate_ will actually change the value
1793
to an integer (so long as the check succeeds).
1794
1795
It also means that when you call the write_ method, the value will be converted
1796
back into a string using the ``str`` function.
1797
1798
To switch this off, and leave values as strings after validation, you need to
1799
set the stringify_ attribute to ``False``. If this is the case, attempting to
1800
set a value to a non-string will raise an error.
1801
1802
1803
Default Values
1804
--------------
1805
1806
You can set a default value in your check. If the value is missing from the
1807
config file then this value will be used instead. This means that your user
1808
only has to supply values that differ from the defaults.
1809
1810
If you *don't* supply a default then for a value to be missing is an error,
1811
and this will show in the `return value`_ from validate.
1812
1813
Additionally you can set the default to be ``None``. This means the value will
1814
be set to ``None`` (the object) *whichever check is used*. (It will be set to
1815
``''`` rather than ``None`` if stringify_ is ``False``). You can use this
1816
to easily implement optional values in your config files. ::
1817
1818
port = integer(0, 100, default=80)
1819
user = string(max=25, default=0)
1820
mode = option('quiet', 'loud', 'silent', default='loud')
1821
nick = string(default=None)
1822
1823
.. note::
1824
1825
Because the default goes through type conversion, it also has to pass the
1826
check.
1827
1828
Note that ``default=None`` is case sensitive.
1829
1830
1831
List Values
1832
~~~~~~~~~~~
1833
1834
It's possible that you will want to specify a list as a default value. To avoid
1835
confusing syntax with commas and quotes you use a list constructor to specify
1836
that keyword arguments are lists. This includes the ``default`` value. This
1837
makes checks look something like : ::
1838
1839
checkname(default=list('val1', 'val2', 'val3'))
1840
1841
This works with all keyword arguments, but is most useful for default values.
1842
1843
1844
Repeated Sections
1845
-----------------
1846
1847
Repeated sections are a way of specifying a configspec for a section that
1848
should be applied to *all* subsections in the same section.
1849
1850
The easiest way of explaining this is to give an example. Suppose you have a
1851
config file that describes a dog. That dog has various attributes, but it can
1852
also have many fleas. You don't know in advance how many fleas there will be,
1853
or what they will be called, but you want each flea validated against the same
1854
configspec.
1855
1856
We can define a section called *fleas*. We want every flea in that section
1857
(every sub-section) to have the same configspec applied to it. We do this by
1858
defining a single section called ``__many__``. ::
1859
1860
[dog]
1861
name = string(default=Rover)
1862
age = float(0, 99, default=0)
1863
1864
[[fleas]]
1865
1866
[[[__many__]]]
1867
bloodsucker = boolean(default=True)
1868
children = integer(default=10000)
1869
size = option(small, tiny, micro, default=tiny)
1870
1871
Every flea on our dog will now be validated using the ``__many__`` configspec.
1872
1873
If you define another sub-section in a section *as well as* a ``__many__`` then
1874
you will get an error.
1875
1876
``__many__`` sections can have sub-sections, including their own ``__many__``
1877
sub-sections. Defaults work in the normal way in repeated sections.
1878
1879
1880
Copy Mode
1881
---------
1882
1883
Because you can specify default values in your configspec, you can use
1884
ConfigObj to write out default config files for your application.
1885
1886
However, normally values supplied from a default in a configspec are *not*
1887
written out by the ``write`` method.
1888
1889
To do this, you need to specify ``copy=True`` when you call validate. As well
1890
as not marking values as default, all the comments in the configspec file
1891
will be copied into your ConfigObj instance.
1892
1893
.. raw:: html
1894
1895
{+coloring}
1896
from configobj import ConfigObj
1897
from validate import Validator
1898
vdt = Validator()
1899
config = ConfigObj(configspec='default.ini')
1900
config.filename = 'new_default.ini'
1901
config.validate(vdt, copy=True)
1902
config.write()
1903
{-coloring}
1904
1905
1906
Validation and Interpolation
1907
----------------------------
1908
1909
String interpolation and validation don't play well together. When validation
1910
changes type it sets the value. If the value uses interpolation, then the
1911
interpolation reference would normally be overwritten. Calling ``write`` would
1912
then use the absolute value and the interpolation reference would be lost.
1913
1914
As a compromise - if the value is unchanged by validation then it is not reset.
1915
This means strings that pass through validation unmodified will not be
1916
overwritten. If validation changes type - the value has to be overwritten, and
1917
any interpolation references are lost {sm;:-(}.
1918
1919
1920
SimpleVal
1921
---------
1922
1923
You may not need a full validation process, but still want to check if all the
1924
expected values are present.
1925
1926
Provided as part of the ConfigObj module is the ``SimpleVal`` object. This has
1927
a dummy ``test`` method that always passes.
1928
1929
The only reason a test will fail is if the value is missing. The return value
1930
from ``validate`` will either be ``True``, meaning all present, or a dictionary
1931
with ``False`` for all missing values/sections.
1932
1933
To use it, you still need to pass in a valid configspec when you create the
1934
ConfigObj, but just set all the values to ``''``. Then create an instance of
1935
``SimpleVal`` and pass it to the ``validate`` method.
1936
1937
As a trivial example if you had the following config file : ::
1938
1939
# config file for an application
1940
port = 80
1941
protocol = http
1942
domain = voidspace
1943
top_level_domain = org.uk
1944
1945
You would write the following configspec : ::
1946
1947
port = ''
1948
protocol = ''
1949
domain = ''
1950
top_level_domain = ''
1951
1952
.. raw:: html
1953
1954
{+coloring}
1955
1956
config = Configobj(filename, configspec=configspec)
1957
val = SimpleVal()
1958
test = config.validate(val)
1959
if test == True:
1960
print 'All values present.'
1961
elif test == False:
1962
print 'No values present!'
1963
else:
1964
for entry in test:
1965
if test[entry] == False:
1966
print '"%s" missing.' % entry
1967
1968
{-coloring}
1969
1970
1971
Empty values
1972
============
1973
1974
Many config files from other applications allow empty values. As of version
1975
4.3.0, ConfigObj will read these as an empty string.
1976
1977
A new option/attribute has been added (``write_empty_values``) to allow
1978
ConfigObj to write empty strings as empty values.
1979
1980
.. raw:: html
1981
1982
{+coloring}
1983
from configobj import ConfigObj
1984
cfg = '''
1985
key =
1986
key2 = # a comment
1987
'''.splitlines()
1988
config = ConfigObj(cfg)
1989
print config
1990
ConfigObj({'key': '', 'key2': ''})
1991
1992
config.write_empty_values = True
1993
for line in config.write():
1994
print line
1995
1996
key =
1997
key2 = # a comment
1998
{-coloring}
1999
2000
2001
unrepr mode
2002
===========
2003
2004
The ``unrepr`` option allows you to store and retrieve the basic Python
2005
data-types using config files. It has to use a slightly different syntax to
2006
normal ConfigObj files. Unsurprisingly it uses Python syntax.
2007
2008
This means that lists are different (they are surrounded by square brackets),
2009
and strings *must* be quoted.
2010
2011
The types that ``unrepr`` can work with are :
2012
2013
| strings, lists tuples
2014
| None, True, False
2015
| dictionaries, integers, floats
2016
| longs and complex numbers
2017
2018
You can't store classes, types or instances.
2019
2020
``unrepr`` uses ``repr(object)`` to write out values, so it currently *doesn't*
2021
check that you are writing valid objects. If you attempt to read an unsupported
2022
value, ConfigObj will raise a ``configobj.UnknownType`` exception.
2023
2024
Values that are triple quoted cased. The triple quotes are removed *before*
2025
converting. This means that you can use triple quotes to write dictionaries
2026
over several lines in your config files. They won't be written like this
2027
though.
2028
2029
If you are writing config files by hand, for use with ``unrepr``, you should
2030
be aware of the following differences from normal ConfigObj syntax :
2031
2032
| List : ``['A List', 'With', 'Strings']``
2033
| Strings : ``"Must be quoted."``
2034
| Backslash : ``"The backslash must be escaped \\"``
2035
2036
These all follow normal Python syntax.
2037
2038
In unrepr mode *inline comments* are not saved. This is because lines are
2039
parsed using the `compiler package <http://docs.python.org/lib/compiler.html>`_
2040
which discards comments.
2041
2042
2043
String Interpolation
2044
====================
2045
2046
ConfigObj allows string interpolation *similar* to the way ``ConfigParser``
2047
or ``string.Template`` work. The value of the ``interpolation`` attribute
2048
determines which style of interpolation you want to use. Valid values are
2049
"ConfigParser" or "Template" (case-insensitive, so "configparser" and
2050
"template" will also work). For backwards compatibility reasons, the value
2051
``True`` is also a valid value for the ``interpolation`` attribute, and
2052
will select ``ConfigParser``-style interpolation. At some undetermined point
2053
in the future, that default *may* change to ``Template``-style interpolation.
2054
2055
For ``ConfigParser``-style interpolation, you specify a value to be
2056
substituted by including ``%(name)s`` in the value.
2057
2058
For ``Template``-style interpolation, you specify a value to be substituted
2059
by including ``${cl}name{cr}`` in the value. Alternately, if 'name' is a valid
2060
Python identifier (i.e., is composed of nothing but alphanumeric characters,
2061
plus the underscore character), then the braces are optional and the value
2062
can be written as ``$name``.
2063
2064
Note that ``ConfigParser``-style interpolation and ``Template``-style
2065
interpolation are mutually exclusive; you cannot have a configuration file
2066
that's a mix of one or the other. Pick one and stick to it. ``Template``-style
2067
interpolation is simpler to read and write by hand, and is recommended if
2068
you don't have a particular reason to use ``ConfigParser``-style.
2069
2070
Interpolation checks first the current section to see if ``name`` is the key
2071
to a value. ('name' is case sensitive).
2072
2073
If it doesn't find it, next it checks the 'DEFAULT' sub-section of the current
2074
section.
2075
2076
If it still doesn't find it, it moves on to check the parent section and the
2077
parent section's 'DEFAULT' subsection, and so on all the way up to the main
2078
section.
2079
2080
If the value specified isn't found in any of these locations, then a
2081
``MissingInterpolationOption`` error is raised (a subclass of
2082
``ConfigObjError``).
2083
2084
If it is found then the returned value is also checked for substitutions. This
2085
allows you to make up compound values (for example directory paths) that use
2086
more than one default value. It also means it's possible to create circular
2087
references. If there are any circular references which would cause an infinite
2088
interpolation loop, an ``InterpolationLoopError`` is raised.
2089
2090
Both of these errors are subclasses of ``InterpolationError``, which is a
2091
subclass of ``ConfigObjError``.
2092
2093
String interpolation and validation don't play well together. This is because
2094
validation overwrites values - and so may erase the interpolation references.
2095
See `Validation and Interpolation`_. (This can only happen if validation
2096
has to *change* the value).
2097
2098
2099
Comments
2100
========
2101
2102
Any line that starts with a '#', possibly preceded by whitespace, is a comment.
2103
2104
If a config file starts with comments then these are preserved as the
2105
initial_comment_.
2106
2107
If a config file ends with comments then these are preserved as the
2108
final_comment_.
2109
2110
Every key or section marker may have lines of comments immediately above it.
2111
These are saved as the ``comments`` attribute of the section. Each member is a
2112
list of lines.
2113
2114
You can also have a comment inline with a value. These are saved as the
2115
``inline_comments`` attribute of the section, with one entry per member of the
2116
section.
2117
2118
Subsections (section markers in the config file) can also have comments.
2119
2120
See `Section Attributes`_ for more on these attributes.
2121
2122
These comments are all written back out by the ``write`` method.
2123
2124
2125
flatten_errors
2126
==============
2127
2128
::
2129
2130
flatten_errors(cfg, res)
2131
2132
Validation_ is a powerful way of checking that the values supplied by the user
2133
make sense.
2134
2135
The validate_ method returns a results dictionary that represents pass or fail
2136
for each value. This doesn't give you any information about *why* the check
2137
failed.
2138
2139
``flatten_errors`` is an example function that turns a results dictionary into
2140
a flat list, that only contains values that *failed*.
2141
2142
``cfg`` is the ConfigObj instance being checked, ``res`` is the results
2143
dictionary returned by ``validate``.
2144
2145
It returns a list of keys that failed. Each member of the list is a tuple : ::
2146
2147
([list of sections...], key, result)
2148
2149
If ``validate`` was called with ``preserve_errors=False`` (the default)
2150
then ``result`` will always be ``False``.
2151
2152
*list of sections* is a flattened list of sections that the key was found
2153
in.
2154
2155
If the section was missing then key will be ``None``.
2156
2157
If the value (or section) was missing then ``result`` will be ``False``.
2158
2159
If ``validate`` was called with ``preserve_errors=True`` and a value
2160
was present, but failed the check, then ``result`` will be the exception
2161
object returned. You can use this as a string that describes the failure.
2162
2163
For example :
2164
2165
*The value "3" is of the wrong type*.
2166
2167
2168
Example Usage
2169
-------------
2170
2171
The output from ``flatten_errors`` is a list of tuples.
2172
2173
Here is an example of how you could present this information to the user.
2174
2175
.. raw:: html
2176
2177
{+coloring}
2178
2179
vtor = validate.Validator()
2180
# ini is your config file - cs is the configspec
2181
cfg = ConfigObj(ini, configspec=cs)
2182
res = cfg.validate(vtor, preserve_errors=True)
2183
for entry in flatten_errors(cfg, res):
2184
# each entry is a tuple
2185
section_list, key, error = entry
2186
if key is not None:
2187
section_list.append(key)
2188
else:
2189
section_list.append('[missing section]')
2190
section_string = ', '.join(section_list)
2191
if error == False:
2192
error = 'Missing value or section.'
2193
print section_string, ' = ', error
2194
2195
{-coloring}
2196
2197
2198
ConfigObj 3
2199
===========
2200
2201
ConfigObj 3 is now deprecated in favour of ConfigObj 4. I can fix bugs in
2202
ConfigObj 3 if needed, though.
2203
2204
For anyone who still needs it, you can download it here: `ConfigObj 3.3.1`_
2205
2206
You can read the old docs at : `ConfigObj 3 Docs`_
2207
2208
.. _ConfigObj 3.3.1: http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=configobj3.zip
2209
.. _ConfigObj 3 Docs: http://www.voidspace.org.uk/python/configobj3.html
2210
2211
2212
CREDITS
2213
=======
2214
2215
ConfigObj 4 is written by (and copyright) `Michael Foord`_ and
2216
`Nicola Larosa`_.
2217
2218
Particularly thanks to Nicola Larosa for help on the config file spec, the
2219
validation system and the doctests.
2220
2221
*validate.py* was originally written by Michael Foord and Mark Andrews.
2222
2223
Thanks to others for input and bugfixes.
2224
2225
2226
LICENSE
2227
=======
2228
2229
ConfigObj, and related files, are licensed under the BSD license. This is a
2230
very unrestrictive license, but it comes with the usual disclaimer. This is
2231
free software: test it, break it, just don't blame us if it eats your data !
2232
Of course if it does, let us know and we'll fix the problem so it doesn't
2233
happen to anyone else {sm;:-)}. ::
2234
2235
Copyright (c) 2004 - 2008, Michael Foord & Nicola Larosa
2236
All rights reserved.
2237
2238
Redistribution and use in source and binary forms, with or without
2239
modification, are permitted provided that the following conditions are
2240
met:
2241
2242
2243
* Redistributions of source code must retain the above copyright
2244
notice, this list of conditions and the following disclaimer.
2245
2246
* Redistributions in binary form must reproduce the above
2247
copyright notice, this list of conditions and the following
2248
disclaimer in the documentation and/or other materials provided
2249
with the distribution.
2250
2251
* Neither the name of Michael Foord nor Nicola Larosa
2252
may be used to endorse or promote products derived from this
2253
software without specific prior written permission.
2254
2255
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
2256
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
2257
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
2258
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
2259
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
2260
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
2261
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
2262
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
2263
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
2264
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
2265
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
2266
2267
You should also be able to find a copy of this license at : `BSD License`_
2268
2269
.. _BSD License: http://www.voidspace.org.uk/python/license.shtml
2270
2271
2272
TODO
2273
====
2274
2275
Better support for configuration from multiple files, including tracking
2276
*where* the original file came from and writing changes to the correct
2277
file.
2278
2279
Make ``newline`` an option (as well as an attribute) ?
2280
2281
``UTF16`` encoded files, when returned as a list of lines, will have the
2282
BOM at the start of every line. Should this be removed from all but the
2283
first line ?
2284
2285
Option to set warning type for unicode decode ? (Defaults to strict).
2286
2287
A method to optionally remove uniform indentation from multiline values.
2288
(do as an example of using ``walk`` - along with string-escape)
2289
2290
Should the results dictionary from validate be an ordered dictionary if
2291
`odict <http://www.voidspace.org.uk/python/odict.html>`_ is available ?
2292
2293
Implement some of the sequence methods (which include slicing) from the
2294
newer ``odict`` ?
2295
2296
Preserve line numbers of values (and possibly the original text of each value).
2297
2298
2299
ISSUES
2300
======
2301
2302
.. note::
2303
2304
Please file any bug reports to `Michael Foord`_ or the **ConfigObj**
2305
`Mailing List`_.
2306
2307
There is currently no way to specify the encoding of a configspec file.
2308
2309
When using ``copy`` mode for validation, it won't copy ``DEFAULT``
2310
sections. This is so that you *can* use interpolation in configspec
2311
files.
2312
2313
``validate`` doesn't report *extra* values or sections.
2314
2315
You can't have a keyword with the same name as a section (in the same
2316
section). They are both dictionary keys - so they would overlap.
2317
2318
ConfigObj doesn't quote and unquote values if ``list_values=False``.
2319
This means that leading or trailing whitespace in values will be lost when
2320
writing. (Unless you manually quote).
2321
2322
Interpolation checks first the current section, then the 'DEFAULT' subsection
2323
of the current section, before moving on to the current section's parent and
2324
so on up the tree.
2325
2326
Does it matter that we don't support the ':' divider, which is supported
2327
by ``ConfigParser`` ?
2328
2329
String interpolation and validation don't play well together. When
2330
validation changes type it sets the value. This will correctly fetch the
2331
value using interpolation - but then overwrite the interpolation reference.
2332
If the value is unchanged by validation (it's a string) - but other types
2333
will be.
2334
2335
2336
CHANGELOG
2337
=========
2338
2339
This is an abbreviated changelog showing the major releases up to version 4.
2340
From version 4 it lists all releases and changes.
2341
2342
2343
2008/02/05 - Version 4.5.2
2344
--------------------------
2345
2346
Distribution updated to include version 0.3.2 of validate_. This means that
2347
``None`` as a default value win configspecs works.
2348
2349
2350
2008/02/05 - Version 4.5.1
2351
--------------------------
2352
2353
Distribution updated to include version 0.3.1 of validate_. This means that
2354
Unicode configspecs now work.
2355
2356
2357
2008/02/05 - Version 4.5.0
2358
--------------------------
2359
2360
ConfigObj will now guarantee that files will be written terminated with a
2361
newline.
2362
2363
ConfigObj will no longer attempt to import the ``validate`` module, until/unless
2364
you call ``ConfigObj.validate`` with ``preserve_errors=True``. This makes it
2365
faster to import.
2366
2367
New methods ``restore_default`` and ``restore_defaults``. ``restore_default``
2368
resets an entry to its default value (and returns that value). ``restore_defaults``
2369
resets all entries to their default value. It doesn't modify entries without a
2370
default value. You must have validated a ConfigObj (which populates the
2371
``default_values`` dictionary) before calling these methods.
2372
2373
BUGFIX: Proper quoting of keys, values and list values that contain hashes
2374
(when writing). When ``list_values=False``, values containing hashes are
2375
triple quoted.
2376
2377
Added the ``reload`` method. This reloads a ConfigObj from file. If the filename
2378
attribute is not set then a ``ReloadError`` (a new exception inheriting from
2379
``IOError``) is raised.
2380
2381
BUGFIX: Files are read in with 'rb' mode, so that native/non-native line endings work!
2382
2383
Minor efficiency improvement in ``unrepr`` mode.
2384
2385
Added missing docstrings for some overidden dictionary methods.
2386
2387
Added the ``reset`` method. This restores a ConfigObj to a freshly created state.
2388
2389
Removed old CHANGELOG file.
2390
2391
2392
2007/02/04 - Version 4.4.0
2393
--------------------------
2394
2395
Official release of 4.4.0
2396
2397
2398
2006/12/17 - Version 4.3.3-alpha4
2399
---------------------------------
2400
2401
By Nicola Larosa
2402
2403
Allowed arbitrary indentation in the ``indent_type`` parameter, removed the
2404
``NUM_INDENT_SPACES`` and ``MAX_INTERPOL_DEPTH`` (a leftover) constants,
2405
added indentation tests (including another docutils workaround, sigh), updated
2406
the documentation.
2407
2408
By Michael Foord
2409
2410
Made the import of ``compiler`` conditional so that ``ConfigObj`` can be used
2411
with `IronPython <http://www.codeplex.com/IronPython>`_.
2412
2413
2414
2006/12/17 - Version 4.3.3-alpha3
2415
---------------------------------
2416
2417
By Nicola Larosa
2418
2419
Added a missing ``self.`` in the _handle_comment method and a related test,
2420
per Sourceforge bug #1523975.
2421
2422
2423
2006/12/09 - Version 4.3.3-alpha2
2424
---------------------------------
2425
2426
By Nicola Larosa
2427
2428
Changed interpolation search strategy, based on this patch by Robin Munn:
2429
http://sourceforge.net/mailarchive/message.php?msg_id=17125993
2430
2431
2432
2006/12/09 - Version 4.3.3-alpha1
2433
---------------------------------
2434
2435
By Nicola Larosa
2436
2437
Added Template-style interpolation, with tests, based on this patch by
2438
Robin Munn: http://sourceforge.net/mailarchive/message.php?msg_id=17125991
2439
(awful archives, bad Sourceforge, bad).
2440
2441
2442
2006/06/04 - Version 4.3.2
2443
--------------------------
2444
2445
Changed error handling, if parsing finds a single error then that error will
2446
be re-raised. That error will still have an ``errors`` and a ``config``
2447
attribute.
2448
2449
Fixed bug where '\\n' terminated files could be truncated.
2450
2451
Bugfix in ``unrepr`` mode, it couldn't handle '#' in values. (Thanks to
2452
Philippe Normand for the report.)
2453
2454
As a consequence of this fix, ConfigObj doesn't now keep inline comments in
2455
``unrepr`` mode. This is because the parser in the `compiler package`_
2456
doesn't keep comments. {sm;:-)}
2457
2458
Error messages are now more useful. They tell you the number of parsing errors
2459
and the line number of the first error. (In the case of multiple errors.)
2460
2461
Line numbers in exceptions now start at 1, not 0.
2462
2463
Errors in ``unrepr`` mode are now handled the same way as in the normal mode.
2464
The errors stored will be an ``UnreprError``.
2465
2466
2467
2006/04/29 - Version 4.3.1
2468
--------------------------
2469
2470
Added ``validate.py`` back into ``configobj.zip``. (Thanks to Stewart
2471
Midwinter)
2472
2473
Updated to `validate.py`_ 0.2.2.
2474
2475
Preserve tuples when calling the ``dict`` method. (Thanks to Gustavo Niemeyer.)
2476
2477
Changed ``__repr__`` to return a string that contains ``ConfigObj({ ... })``.
2478
2479
Change so that an options dictionary isn't modified by passing it to ConfigObj.
2480
(Thanks to Artarious.)
2481
2482
Added ability to handle negative integers in ``unrepr``. (Thanks to Kevin
2483
Dangoor.)
2484
2485
2486
2006/03/24 - Version 4.3.0
2487
--------------------------
2488
2489
Moved the tests and the CHANGELOG (etc) into a separate file. This has reduced
2490
the size of ``configobj.py`` by about 40%.
2491
2492
Added the ``unrepr`` mode to reading and writing config files. Thanks to Kevin
2493
Dangoor for this suggestion.
2494
2495
Empty values are now valid syntax. They are read as an empty string ``''``.
2496
(``key =``, or ``key = # comment``.)
2497
2498
``validate`` now honours the order of the configspec.
2499
2500
Added the ``copy`` mode to validate. Thanks to Louis Cordier for this
2501
suggestion.
2502
2503
Fixed bug where files written on windows could be given ``'\r\r\n'`` line
2504
terminators.
2505
2506
Fixed bug where last occurring comment line could be interpreted as the
2507
final comment if the last line isn't terminated.
2508
2509
Fixed bug where nested list values would be flattened when ``write`` is
2510
called. Now sub-lists have a string representation written instead.
2511
2512
Deprecated ``encode`` and ``decode`` methods instead.
2513
2514
You can now pass in a ConfigObj instance as a configspec (remember to read
2515
the configspec file using ``list_values=False``).
2516
2517
Sorted footnotes in the docs.
2518
2519
2520
2006/02/16 - Version 4.2.0
2521
--------------------------
2522
2523
Removed ``BOM_UTF8`` from ``__all__``.
2524
2525
The ``BOM`` attribute has become a boolean. (Defaults to ``False``.) It is
2526
*only* ``True`` for the ``UTF16/UTF8`` encodings.
2527
2528
File like objects no longer need a ``seek`` attribute.
2529
2530
Full unicode support added. New options/attributes ``encoding``,
2531
``default_encoding``.
2532
2533
ConfigObj no longer keeps a reference to file like objects. Instead the
2534
``write`` method takes a file like object as an optional argument. (Which
2535
will be used in preference of the ``filename`` attribute if that exists as
2536
well.)
2537
2538
utf16 files decoded to unicode.
2539
2540
If ``BOM`` is ``True``, but no encoding specified, then the utf8 BOM is
2541
written out at the start of the file. (It will normally only be ``True`` if
2542
the utf8 BOM was found when the file was read.)
2543
2544
Thanks to Aaron Bentley for help and testing on the unicode issues.
2545
2546
File paths are *not* converted to absolute paths, relative paths will
2547
remain relative as the ``filename`` attribute.
2548
2549
Fixed bug where ``final_comment`` wasn't returned if ``write`` is returning
2550
a list of lines.
2551
2552
Deprecated ``istrue``, replaced it with ``as_bool``.
2553
2554
Added ``as_int`` and ``as_float``.
2555
2556
2557
2005/12/14 - Version 4.1.0
2558
--------------------------
2559
2560
Added ``merge``, a recursive update.
2561
2562
Added ``preserve_errors`` to ``validate`` and the ``flatten_errors``
2563
example function.
2564
2565
Thanks to Matthew Brett for suggestions and helping me iron out bugs.
2566
2567
Fixed bug where a config file is *all* comment, the comment will now be
2568
``initial_comment`` rather than ``final_comment``.
2569
2570
Validation no longer done on the 'DEFAULT' section (only in the root level).
2571
This allows interpolation in configspecs.
2572
2573
Also use the new list syntax in validate_ 0.2.1. (For configspecs).
2574
2575
2576
2005/12/02 - Version 4.0.2
2577
--------------------------
2578
2579
Fixed bug in ``create_empty``. Thanks to Paul Jimenez for the report.
2580
2581
2582
2005/11/05 - Version 4.0.1
2583
--------------------------
2584
2585
Fixed bug in ``Section.walk`` when transforming names as well as values.
2586
2587
Added the ``istrue`` method. (Fetches the boolean equivalent of a string
2588
value).
2589
2590
Fixed ``list_values=False`` - they are now only quoted/unquoted if they
2591
are multiline values.
2592
2593
List values are written as ``item, item`` rather than ``item,item``.
2594
2595
2596
2005/10/17 - Version 4.0.0
2597
--------------------------
2598
2599
**ConfigObj 4.0.0 Final**
2600
2601
Fixed bug in ``setdefault``. When creating a new section with setdefault the
2602
reference returned would be to the dictionary passed in *not* to the new
2603
section. Bug fixed and behaviour documented.
2604
2605
Obscure typo/bug fixed in ``write``. Wouldn't have affected anyone though.
2606
2607
2608
2005/09/09 - Version 4.0.0 beta 5
2609
---------------------------------
2610
2611
Removed ``PositionError``.
2612
2613
Allowed quotes around keys as documented.
2614
2615
Fixed bug with commas in comments. (matched as a list value)
2616
2617
2618
2005/09/07 - Version 4.0.0 beta 4
2619
---------------------------------
2620
2621
Fixed bug in ``__delitem__``. Deleting an item no longer deletes the
2622
``inline_comments`` attribute.
2623
2624
Fixed bug in initialising ConfigObj from a ConfigObj.
2625
2626
Changed the mailing list address.
2627
2628
2629
2005/08/28 - Version 4.0.0 beta 3
2630
---------------------------------
2631
2632
Interpolation is switched off before writing out files.
2633
2634
Fixed bug in handling ``StringIO`` instances. (Thanks to report from
2635
Gustavo Niemeyer.)
2636
2637
Moved the doctests from the ``__init__`` method to a separate function.
2638
(For the sake of IDE calltips).
2639
2640
2641
2005/08/25 - Version 4.0.0 beta 2
2642
---------------------------------
2643
2644
Amendments to *validate.py*.
2645
2646
First public release.
2647
2648
2649
2005/08/21 - Version 4.0.0 beta 1
2650
---------------------------------
2651
2652
Reads nested subsections to any depth.
2653
2654
Multiline values.
2655
2656
Simplified options and methods.
2657
2658
New list syntax.
2659
2660
Faster, smaller, and better parser.
2661
2662
Validation greatly improved. Includes:
2663
2664
* type conversion
2665
* default values
2666
* repeated sections
2667
2668
Improved error handling.
2669
2670
Plus lots of other improvements. {sm;:grin:}
2671
2672
2673
2004/05/24 - Version 3.0.0
2674
--------------------------
2675
2676
Several incompatible changes: another major overhaul and change. (Lots of
2677
improvements though).
2678
2679
Added support for standard config files with sections. This has an entirely
2680
new interface: each section is a dictionary of values.
2681
2682
Changed the update method to be called writein: update clashes with a dict
2683
method.
2684
2685
Made various attributes keyword arguments, added several.
2686
2687
Configspecs and orderlists have changed a great deal.
2688
2689
Removed support for adding dictionaries: use update instead.
2690
2691
Now subclasses a new class called caselessDict. This should add various
2692
dictionary methods that could have caused errors before.
2693
2694
It also preserves the original casing of keywords when writing them back out.
2695
2696
Comments are also saved using a ``caselessDict``.
2697
2698
Using a non-string key will now raise a ``TypeError`` rather than converting
2699
the key.
2700
2701
Added an exceptions keyword for *much* better handling of errors.
2702
2703
Made ``creatempty=False`` the default.
2704
2705
Now checks indict *and* any keyword args. Keyword args take precedence over
2706
indict.
2707
2708
``' ', ':', '=', ','`` and ``'\t'`` are now all valid dividers where the
2709
keyword is unquoted.
2710
2711
ConfigObj now does no type checking against configspec when you set items.
2712
2713
delete and add methods removed (they were unnecessary).
2714
2715
Docs rewritten to include all this gumph and more; actually ConfigObj is
2716
*really* easy to use.
2717
2718
Support for stdout was removed.
2719
2720
A few new methods added.
2721
2722
Charmap is now incorporated into ConfigObj.
2723
2724
2725
2004/03/14 - Version 2.0.0 beta
2726
-------------------------------
2727
2728
Re-written it to subclass dict. My first forays into inheritance and operator
2729
overloading.
2730
2731
The config object now behaves like a dictionary.
2732
2733
I've completely broken the interface, but I don't think anyone was really
2734
using it anyway.
2735
2736
This new version is much more 'classy'. {sm;:wink:}
2737
2738
It will also read straight from/to a filename and completely parse a config
2739
file without you *having* to supply a config spec.
2740
2741
Uses listparse, so can handle nested list items as values.
2742
2743
No longer has getval and setval methods: use normal dictionary methods, or add
2744
and delete.
2745
2746
2747
2004/01/29 - Version 1.0.5
2748
--------------------------
2749
2750
Version 1.0.5 has a couple of bugfixes as well as a couple of useful additions
2751
over previous versions.
2752
2753
Since 1.0.0 the buildconfig function has been moved into this distribution,
2754
and the methods reset, verify, getval and setval have been added.
2755
2756
A couple of bugs have been fixed.
2757
2758
2759
Origins
2760
-------
2761
2762
ConfigObj originated in a set of functions for reading config files in the
2763
`atlantibots <http://www.voidspace.org.uk/atlantibots/>`_ project. The original
2764
functions were written by Rob McNeur.
2765
2766
2767
----------
2768
2769
2770
Footnotes
2771
=========
2772
2773
.. [#] And if you discover any bugs, let us know. We'll fix them quickly.
2774
2775
.. [#] If you specify a filename that doesn't exist, ConfigObj will assume you
2776
are creating a new one. See the *create_empty* and *file_error* options_.
2777
2778
.. [#] They can be byte strings (*ordinary* strings) or Unicode.
2779
2780
.. [#] Except we don't support the RFC822 style line continuations, nor ':' as
2781
a divider.
2782
2783
.. [#] This is a change in ConfigObj 4.2.0. Note that ConfigObj doesn't call
2784
the seek method of any file like object you pass in. You may want to call
2785
``file_object.seek(0)`` yourself, first.
2786
2787
.. [#] A side effect of this is that it enables you to copy a ConfigObj :
2788
2789
.. raw:: html
2790
2791
{+coloring}
2792
2793
# only copies members
2794
# not attributes/comments
2795
config2 = ConfigObj(config1)
2796
2797
{-coloring}
2798
2799
The order of values and sections will not be preserved, though.
2800
2801
.. [#] Other than lists of strings.
2802
2803
.. [#] The exception is if it detects a ``UTF16`` encoded file which it
2804
must decode before parsing.
2805
2806
.. [#] The method signature shows that this method takes
2807
two arguments. The second is the section to be written. This is because the
2808
``write`` method is called recursively.
2809
2810
.. [#] The dict method doesn't actually use the deepcopy mechanism. This means
2811
if you add nested lists (etc) to your ConfigObj, then the dictionary
2812
returned by dict may contain some references. For all *normal* ConfigObjs
2813
it will return a deepcopy.
2814
2815
.. [#] Passing ``(section, key)`` rather than ``(value, key)`` allows you to
2816
change the value by setting ``section[key] = newval``. It also gives you
2817
access to the *rename* method of the section.
2818
2819
.. [#] Minimum required version of *validate.py* 0.2.0 .
2820
2821
2822
.. note::
2823
2824
Rendering this document with docutils also needs the
2825
textmacros module and the PySrc CSS stuff. See
2826
http://www.voidspace.org.uk/python/firedrop2/textmacros.shtml
2827
2828
2829
.. raw:: html
2830
2831
<div align="center">
2832
<p>
2833
<a href="http://www.python.org">
2834
<img src="images/new_python.gif" width="100" height="103" border="0"
2835
alt="Powered by Python" />
2836
</a>
2837
<a href="http://sourceforge.net">
2838
<img src="http://sourceforge.net/sflogo.php?group_id=123265&type=1" width="88" height="31" border="0" alt="SourceForge.net Logo" />
2839
</a>
2840
<a href="http://www.opensource.org">
2841
<img src="images/osi-certified-120x100.gif" width="120" height="100" border="0"
2842
alt="Certified Open Source"/>
2843
</a>
2844
</p>
2845
<p>
2846
<a href="http://www.voidspace.org.uk/python/index.shtml">
2847
<img src="images/pythonbanner.gif" width="468" height="60"
2848
alt="Python on Voidspace" border="0" />
2849
</a>
2850
</p>
2851
2852
</div>
2853
2854
.. _listquote: http://www.voidspace.org.uk/python/modules.shtml#listquote
2855
.. _Michael Foord: http://www.voidspace.org.uk/python/weblog/index.shtml
2856
.. _Nicola Larosa: http://www.teknico.net
Loggerhead is a web-based interface for Breezy
Version: 2.0.1