Author: | Michael Foord |
---|---|
Author: | Nicola Larosa |
Version: | ConfigObj 4.1.0 |
Date: | 2005/12/14 |
Homepage: | ConfigObj Homepage |
Sourceforge: | Sourceforge |
License: | BSD License |
Support: | Mailing List |
ConfigObj is a simple but powerful config file reader and writer: an ini file round tripper. Its main feature is that it is very easy to use, with a straightforward programmer's interface and a simple syntax for config files. It has lots of other features though :
Nested sections (subsections), to any level
List values
Multiple line values
String interpolation (substitution)
Integrated with a powerful validation system
- including automatic type checking/conversion
- repeated sections
- and allowing default values
All comments in the file are preserved
The order of keys/sections is preserved
No external dependencies
ConfigObj 4 is a complete rewrite of ConfigObj. A great deal has been simplified and improved [1] since ConfigObj 3. If you have used ConfigObj before then you need to read the section on backwards compatibility.
ConfigObj now has a barrage [2] of doctests built into it, testing almost every feature. Run python configobj.py -v to see them in action. Despite the tests, ConfigObj 4 is actually smaller than version 3 and has no external dependencies.
For support and bug reports please use the ConfigObj Mailing List.
Hint
There is an article on using ConfigObj for Data Persistence.
The code from that article is available as ConfigPersist.py.
The current version is 4.1.0, dated 14th December 2005. ConfigObj 4 is
now stable. We still expect to pick up a few bugs along the way though [3].
You can get ConfigObj in the following ways :
configobj.py from Voidspace
ConfigObj has no external dependencies. This file is sufficient to access all the functionality except Validation.
configobj.zip from Voidspace
This also contains validate.py , the API Docs and this document.
The latest development version can be obtained from the Subversion Repository.
validate.py from Voidspace
You can also download configobj.zip from Sourceforge
configobj.zip contains this document and full API Docs, generated by the EpyDoc program.
ConfigObj is also part of the Pythonutils set of modules. This contains various other useful modules, and is required by many of the Voidspace Python Projects.
The outstanding feature of using ConfigObj is simplicity. Most functions can be performed with single line commands.
The normal way to read a config file, is to give ConfigObj the filename :
You can also pass the config file in as a list of lines, or a StringIO instance, so it doesn't matter where your config data comes from.
You can then access members of your config file as a dictionary. Subsections will also be dictionaries.
Creating a new config file is just as easy as reading one. You can specify a filename when you create the ConfigObj, or do it later [4].
If you don't set a filename, then the write method will return a list of lines instead of writing to file. See the write method for more details.
Here we show creating an empty ConfigObj, setting a filename and some values, and then writing to file :
Caution!
Keywords and section names can only be strings [5]. Attempting to set anything else will raise a ValueError.
The config files that ConfigObj will read and write are based on the 'INI' format. This means it will read and write files created for ConfigParser [6].
Keywords and values are separated by an '=', and section markers are between square brackets. Keywords, values, and section names can be surrounded by single or double quotes. Indentation is not significant, but can be preserved.
Subsections are indicated by repeating the square brackets in the section marker. You nest levels by using more brackets.
You can have list values by separating items with a comma, and values spanning multiple lines by using triple quotes (single or double).
For full details on all these see the config file format. Here's an example to illustrate :
# This is the 'initial_comment' # Which may be several lines keyword1 = value1 'keyword 2' = 'value 2' [ "section 1" ] # This comment goes with keyword 3 keyword 3 = value 3 'keyword 4' = value4, value 5, 'value 6' [[ sub-section ]] # an inline comment # sub-section is inside "section 1" 'keyword 5' = 'value 7' 'keyword 6' = '''A multiline value, that spans more than one line :-) The line breaks are included in the value.''' [[[ sub-sub-section ]]] # sub-sub-section is *in* 'sub-section' # which is in 'section 1' 'keyword 7' = 'value 8' [section 2] # an inline comment keyword8 = "value 9" keyword9 = value10 # an inline comment # The 'final_comment' # Which also may be several lines
You don't need to specify an infile. If you omit it, an empty ConfigObj will be created. infile can be :
There are various options that control the way ConfigObj behaves. They can be passed in as a dictionary of options, or as keyword arguments. Explicit keyword arguments override the dictionary.
All of the options are available as attributes after the config file has been parsed.
ConfigObj has the following options (with the default values shown) :
'raise_errors': False
When parsing, it is possible that the config file will be badly formed. The default is to parse the whole file and raise a single error at the end. You can set raise_errors = True to have errors raised immediately. See the exceptions section for more details.
Altering this value after initial parsing has no effect.
'list_values': True
If True (the default) then list values are possible. If False, the values are not parsed for lists.
If list_values = False then single line values are not quoted or unqouted when reading and writing.
- Changing this value affects whether single line values will be quoted or
not when writing.
'create_empty': False
If this value is True and the file specified by infile doesn't exist, ConfigObj will create an empty file. This can be a useful test that the filename makes sense: an impossible filename will cause an error.
Altering this value after initial parsing has no effect.
'file_error': False
If this value is True and the file specified by infile doesn't exist, ConfigObj will raise an IOError.
Altering this value after initial parsing has no effect.
'interpolation': True
Whether string interpolation is switched on or not. It is on (True) by default.
You can set this attribute to change whether string interpolation is done when values are fetched. See the interpolation section for more details.
'configspec': None
If you want to use the validation system, you supply a configspec. This is effectively a type of config file that specifies a check for each member. This check can be used to do type conversion as well as check that the value is within your required parameters.
You provide a configspec in the same way as you do the initial file: a filename, or list of lines, etc. See the validation section for full details on how to use the system.
When parsed, every section has a configspec with a dictionary of configspec checks for that section.
'stringify': True
If you use the validation scheme, it can do type checking and conversion for you. This means you may want to set members to integers, or other non-string values.
If 'stringify' is set to True (default) then non-string values will be converted to strings when you write the config file. The validation process converts values from strings to the required type.
If 'stringify' is set to False, attempting to set a member to a non-string value [9] will raise a TypeError (no type conversion is done by validation).
'indent_type': ' '
Indentation is not significant; it can however be present in the output config. Allowable values are: '' (no indentation), ' ' (indentation with spaces, fixed at four per level), or '\t' (indentation with tabs, one tab per level).
If this option is not specified, and the ConfigObj is initialised with a dictionary, the indentation used in the output is the default one, that is, spaces.
If this option is not specified, and the ConfigObj is initialised with a list of lines or a file, the indentation used in the first indented line is selected and used in all output lines. If no input line is indented, no output line will be either.
If this option is specified, the option value is used in the output config, overriding the type of indentation in the input config (if any).
The ConfigObj is a subclass of an object called Section, which is itself a subclass of dict, the builtin dictionary type. This means it also has all the normal dictionary methods.
In addition, the encode, decode, walk, istrue, merge, and dict methods of section may be useful. The sections and subsections are also instances of Section. Read about Sections for details of all the methods.
Hint
The merge method of sections is a recursive update.
You can use this to merge sections, or even whole ConfigObjs, into each other.
You would typically use this to create a default ConfigObj and then merge in user settings. This way users only need to specify values that are different from the default.
The public methods available on ConfigObj are :
write()
This method takes no arguments [10]. It writes the current ConfigObj. What that means depends on the filename attribute of the ConfigObj.
First the 'initial_comment' is written, then the config file, followed by the 'final_comment'. Comment lines and inline comments are written with each key/value.
validate(alidator, preserve_errors=False)
The validate method uses the validate module to do the validation.
This method validates the ConfigObj against the configspec. By doing type conversion as well, it can abstract away the config file altogether and present the config data to your application (in the types it expects it to be).
If the configspec attribute of the ConfigObj is None, it raises a ValueError.
If the stringify attribute is set, this process will convert values to the type defined in the configspec.
The validate method uses checks specified in the configspec and defined in the Validator object. It is very easy to extend.
The configspec looks like the config file, but instead of the value, you specify the check (and any default value). See the validation section for details.
Hint
If your ConfigObj is only comprised of basic data types, then you can use a function from the ConfigPersist.py module to auto-generate your configspec.
By default, the validate method either returns True (everything passed) or a dictionary of True/False representing pass/fail. The dictionary follows the structure of the ConfigObj.
If a whole section passes then it is replaced with the value True. If a whole section fails, then it is replaced with the value False.
If a value is missing, and there is no default in the check, then the check automatically fails.
The validate method takes an optional keyword argument preserve_errors. If you set this to True, instead of getting False for failed checks you get the actual error object from the validate module. This usually contains useful information about why the check failed.
See the flatten_errors function for how to turn your results dictionary into a useful list of error messages.
Even if preserve_errors is True, missing keys or sections will still be represented by a False in the results dictionary.
In the check in your configspec, you can specify a default to be used - by using the default keyword. E.g.
key1 = integer(0, 30, default=15) key2 = integer(default=15) key3 = boolean(default=True) key4 = option('Hello', 'Goodbye', 'Not Today', default='Not Today')
If the configspec check supplies a default and the value is missing in the config, then the default will be set in your ConfigObj. (It is still passed to the Validator so that type conversion can be done: this means the default value must still pass the check.)
ConfigObj keeps a record of which values come from defaults, using the defaults attribute of sections. Any key in this list isn't written out by the write method. If a key is set from outside (even to the same value) then it is removed from the defaults list.
There is additionally a special case default value of None. If you set the default value to None and the value is missing, the value will always be set to None. As the other checks don't return None (unless you implement your own that do), you can tell that this value came from a default value (and was missing from the config file). It allows an easy way of implementing optional values. Simply check (and ignore) members that are set to None.
Note
If stringify is False then default=None returns '' instead of None. This is because setting a value to a non-string raises an error if stringify is unset.
The default value can be a list. See List Values for the way to do this.
Writing invalid default values is a guaranteed way of confusing your users. Default values must pass the check.
In the configspec it is possible to cause every sub-section in a section to be validated using the same configspec. You do this with a section in the configspec called __many__. Every sub-section in that section has the __many__ configspec applied to it (without you having to explicitly name them in advance).
If you define a __many__ type section it must the only sub-section in that section. Having a __many__ and other sub-sections defined in the same section will raise a RepeatSectionError.
Your __many__ section can have nested subsections, which can also include __many__ type sections.
See Repeated Sections for examples.
If you just want to check if all members are present, then you can use the SimpleVal object that comes with ConfigObj. It only fails members if they are missing.
Write a configspec that has all the members you want to check for, but set every section to ''.
A ConfigObj has the following attributes :
Note
This doesn't include comments, inline_comments, defaults, or configspec. These are actually attributes of Sections.
It also has the following attributes as a result of parsing. They correspond to options when the ConfigObj was created, but changing them has no effect.
ConfigObj can perform string interpolation in a similar way to ConfigParser. See the interpolation section for full details.
If interpolate is set to False, then interpolation is not done when you fetch values.
If this attribute is set (True) then the validate method changes the values in the ConfigObj. These are turned back into strings when write is called.
If stringify is unset (False) then attempting to set a value to a non string (or a list of strings) will raise a TypeError.
If the initial config file started with the UTF8 Unicode signature (known slightly incorrectly as the BOM), then this value will be set to the UTF8 BOM. Otherwise it is None.
If it is set, then it is written out by the write method.
This is a list of lines. If the ConfigObj is created from an existing file, it will contain any lines of comments before the start of the members.
If you create a new ConfigObj, this will be an empty list.
The write method puts these lines before it starts writing out the members.
This is a list of lines. If the ConfigObj is created from an existing file, it will contain any lines of comments after the last member.
If you create a new ConfigObj, this will be an empty list.
The write method puts these lines after it finishes writing out the members.
This attribute is True or False. If set to False then values are not parsed for list values. In addition single line values are not unquoted.
This allows you to do your own parsing of values. It exists primarily to support the reading of the configspec - but has other use cases.
For example you could use the LineParser from the listquote module to read values for nested lists.
Single line values aren't quoted when writing - but multiline values are handled as normal.
Caution!
This behaviour was changed in version 4.0.1.
Prior to this, single line values might have been quoted; even with list_values=False. This means that files written by ConfigObj could now be incompatible - and need the quotes removing by hand.
You saw an example config file in the Config Files section. Here is a fuller specification of the config files used and created by ConfigObj.
The basic pattern for keywords is :
# comment line # comment line keyword = value # inline comment
Both keyword and value can optionally be surrounded in quotes. The equals sign is the only valid divider.
Values can have comments on the lines above them, and an inline comment after them. This, of course, is optional. See the comments section for details.
If a keyword or value starts or ends with whitespace, or contains a quote mark or comma, then it should be surrounded by quotes. Quotes are not necessary if whitespace is surrounded by non-whitespace.
Values can also be lists. Lists are comma separated. You indicate a single member list by a trailing comma. An empty list is shown by a single comma :
keyword1 = value1, value2, value3 keyword2 = value1, # a single member list keyword3 = , # an empty list
Values that contain line breaks (multi-line values) can be surrounded by triple quotes. These can also be used if a value contains both types of quotes. List members cannot be surrounded by triple quotes :
keyword1 = ''' A multi line value on several lines''' # with a comment keyword2 = '''I won't be "afraid".''' # keyword3 = """ A multi line value on several lines""" # with a comment keyword4 = """I won't be "afraid"."""
Warning
There is no way of safely quoting values that contain both types of triple quotes.
A line that starts with a '#', possibly preceded by whitespace, is a comment.
New sections are indicated by a section marker line. That is the section name in square brackets. Whitespace around the section name is ignored. The name can be quoted with single or double quotes. The marker can have comments before it and an inline comment after it :
# The First Section [ section name 1 ] # first section keyword1 = value1 # The Second Section [ "section name 2" ] # second section keyword2 = value2
Any subsections (sections that are inside the current section) are designated by repeating the square brackets before and after the section name. The number of square brackets represents the nesting level of the sub-section. Square brackets may be separated by whitespace; such whitespace, however, will not be present in the output config written by the write method.
Indentation is not significant, but can be preserved. See the description of the indent_type option, in the ConfigObj specifications chapter, for the details.
A NestingError will be raised if the number of the opening and the closing brackets in a section marker is not the same, or if a sub-section's nesting level is greater than the nesting level of it parent plus one.
In the outer section, single values can only appear before any sub-section. Otherwise they will belong to the sub-section immediately before them.
# initial comment keyword1 = value1 keyword2 = value2 [section 1] keyword1 = value1 keyword2 = value2 [[sub-section]] # this is in section 1 keyword1 = value1 keyword2 = value2 [[[nested section]]] # this is in sub section keyword1 = value1 keyword2 = value2 [[sub-section2]] # this is in section 1 again keyword1 = value1 keyword2 = value2 [[sub-section3]] # this is also in section 1, indentation is misleading here keyword1 = value1 keyword2 = value2 # final comment
When parsed, the above config file produces the following data structure :
Sections are ordered: note how the structure of the resulting ConfigObj is in the same order as the original file.
Every section in a ConfigObj has certain properties. The ConfigObj itself also has these properties, because it too is a section (sometimes called the root section).
Section is a subclass of the standard new-class dictionary, therefore it has all the methods of a normal dictionary. This means you can update and clear sections.
Note
You create a new section by assigning a member to be a dictionary.
The new Section is created from the dictionary, but isn't the same thing as the dictionary. (So references to the dictionary you use to create the section aren't references to the new section).
Note the following.
If you now change vals, the changes won't be reflected in config['vals'].
A section is ordered, following its scalars and sections attributes documented below. This means that the following dictionary attributes return their results in order.
'__iter__'
More commonly known as for member in section:.
'__repr__' and '__str__'
Any time you print or display the ConfigObj.
'items'
'iteritems'
'iterkeys'
'itervalues'
'keys'
'popitem'
'values'
main
A reference to the main ConfigObj.
parent
A reference to the 'parent' section, the section that this section is a member of.
On the ConfigObj this attribute is a reference to itself. You can use this to walk up the sections, stopping when section.parent is section.
depth
The nesting level of the current section.
If you create a new ConfigObj and add sections, 1 will be added to the depth level between sections.
defaults
This attribute is a list of scalars that came from default values. Values that came from defaults aren't written out by the write method. Setting any of these values in the section removes them from the defaults list.
scalars, sections
These attributes are normal lists, representing the order that members, single values and subsections appear in the section. The order will either be the order of the original config file, or the order that you added members.
The order of members in this lists is the order that write creates in the config file. The scalars list is output before the sections list.
Adding or removing members also alters these lists. You can manipulate the lists directly to alter the order of members.
Warning
If you alter the scalars, sections, or defaults attributes so that they no longer reflect the contents of the section, you will break your ConfigObj.
See also the rename method.
comments
This is a dictionary of comments associated with each member. Each entry is a list of lines. These lines are written out before the member.
inline_comments
This is another dictionary of comments associated with each member. Each entry is a string that is put inline with the member.
configspec
The configspec attribute is a dictionary mapping scalars to checks. A check defines the expected type and possibly the allowed values for a member.
The configspec has the same format as a config file, but instead of values it has a specification for the value (which may include a default value). The validate method uses it to check the config file makes sense. If a configspec is passed in when the ConfigObj is created, then it is parsed and broken up to become the configspec attribute of each section.
If you didn't pass in a configspec, this attribute will be None on the root section (the main ConfigObj).
You can set the configspec attribute directly on a section.
See the validation section for full details of how to write configspecs.
dict
This method takes no arguments. It returns a deep copy of the section as a dictionary. All subsections will also be dictionaries, and list values will be copies, rather than references to the original [11].
rename
rename(oldkey, newkey)
This method renames a key, without affecting its position in the sequence.
It is mainly implemented for the encode and decode methods, which provide some Unicode support.
merge
merge(indict)
This method is a recursive update method. It allows you to merge two config files together.
You would typically use this to create a default ConfigObj and then merge in user settings. This way users only need to specify values that are different from the default.
For example :
# def_cfg contains your default config settings
# user_cfg contains the user settings
cfg = ConfigObj(def_cfg)
usr = ConfigObj(user_cfg)
#
cfg.merge(usr)
"""
cfg now contains a combination of the default settings and the user
settings.
The user settings will have overwritten any of the default ones.
"""
walk
This method can be used to transform values and names. See walking a section for examples and explanation.
decode
decode(encoding)
This method decodes names and values into Unicode objects, using the supplied encoding.
Because of the way ConfigObj reads files, config files should be in an ASCII compatible encoding. See encodings for more details.
encode
encode(encoding)
This method is the opposite of decode
.
It encodes names and values using the supplied encoding. If any of your names/values are strings rather than Unicode, Python will have to do an implicit decode first.
See encodings for more details.
istrue
istrue(key)
Returns True if the key contains a string that represents True, or is the True object.
Returns False if the key contains a string that represents False, or is the False object.
Raises a ValueError if the key contains anything else.
Strings that represent True are (not case sensitive) :
true, yes, on, 1Strings that represent False are :
false, no, off, 0
Note
The walk method allows you to call a function on every member/name.
walk is a method of the Section object. This means it is also a method of ConfigObj.
It walks through every member and calls a function on the keyword and value. It walks recursively through subsections.
It returns a dictionary of all the computed values.
If the function raises an exception, the default is to propagate the error, and stop. If raise_errors=False then it sets the return value for that keyword to False instead, and continues. This is similar to the way validation works.
Your function receives the arguments (section, key). The current value is then section[key] [12]. Any unrecognised keyword arguments you pass to walk, are passed on to the function.
Normally walk just recurses into subsections. If you are transforming (or checking) names as well as values, then you want to be able to change the names of sections. In this case set call_on_sections to True. Now, on encountering a sub-section, first the function is called for the whole sub-section, and then it recurses into it's members. This means your function must be able to handle receiving dictionaries as well as strings and lists.
If you are using the return value from walk and call_on_sections, note that walk discards the return value when it calls your function.
Caution!
You can use walk to transform the names of members of a section but you mustn't add or delete members.
Examples that use the walk method are the encode and decode methods. They both define a function and pass it to walk. Because these functions transform names as well as values (from byte strings to Unicode) they set call_on_sections=True.
To see how they do it, read the source Luke .
You can use this for transforming all values in your ConfigObj. For example you might like the nested lists from ConfigObj 3. This was provided by the listquote module. You could switch off the parsing for list values (list_values=False) and use listquote to parse every value.
Another thing you might want to do is use the Python escape codes in your values. You might be used to using \n for line feed and \t for tab. Obviously we'd need to decode strings that come from the config file (using the escape codes). Before writing out we'll need to put the escape codes back in encode.
As an example we'll write a function to use with walk, that encodes or decodes values using the string-escape codec.
The function has to take each value and set the new value. As a bonus we'll create one function that will do decode or encode depending on a keyword argument.
We don't want to work with section names, we're only transforming values, so we can leave call_on_sections as False. This means the two datatypes we have to handle are strings and lists, we can ignore everything else. (We'll treat tuples as lists as well).
We're not using the return values, so it doesn't need to return anything, just change the values if appropriate.
Here's a simple example of using walk to transform names and values. One usecase of this would be to create a standard config file with placeholders for section and keynames. You can then use walk to create new config files and change values and member names :
There are several places where ConfigObj may raise exceptions (other than because of bugs).
filename doesn't exist and file_error=True, an IOError will be raised.
stringify=False, a TypeError will be raised.
A badly built config file will cause parsing errors.
A parsing error can also occur when reading a configspec.
create circular references (recursion).
(in a configspec), a RepeatSectionError will be raised.
Number 6 is explained in the validation section.
This section is about errors raised during parsing.
The base error class is ConfigObjError. This is a subclass of SyntaxError, so you can trap for SyntaxError without needing to directly import any of the ConfigObj exceptions.
The following other exceptions are defined (all deriving from ConfigObjError) :
NestingError
This error indicates either a mismatch in the brackets in a section marker, or an excessive level of nesting.
ParseError
This error indicates that a line is badly written. It is neither a valid key = value line, nor a valid section marker line, nor a comment line.
DuplicateError
The keyword or section specified already exists.
ConfigspecError
An error occured whilst parsing a configspec.
When parsing a configspec, ConfigObj will stop on the first error it encounters. It will raise a ConfigspecError. This will have an error attribute, which is the actual error that was raised.
Behavior when parsing a config file depends on the option raise_errors. If ConfigObj encounters an error while parsing a config file:
If raise_errors=True then ConfigObj will raise the appropriate error and parsing will stop.
If raise_errors=False (the default) then parsing will continue to the end and all errors will be collected.
In the second case a ConfigObjError is raised after parsing has stopped. The error raised has a config attribute, which is the parts of the ConfigObj that parsed successfully. It also has an attribute errors, which is a list of all the errors raised. Each entry in the list is an instance of the appropriate error type. Each one has the following attributes (useful for delivering a sensible error message to your user) :
Note
One wrongly written line could break the basic structure of your config
file. This could cause every line after it to flag an error, so having a
list of all the lines that caused errors may not be as useful as it sounds.
.
Validation is done through a combination of the configspec and a Validator object. For this you need validate.py [13]. See downloading if you don't have a copy.
Validation can perform two different operations :
is an integer between one and six, or is a choice from a specific set of options.
your values is a port number, validation will turn it into an integer for you.
So validation can act as a transparent layer between the datatypes of your application configuration (boolean, integers, floats, etc) and the text format of your config file.
The validate method checks members against an entry in the configspec. Your configspec therefore resembles your config file, with a check for every member.
In order to perform validation you need a Validator object. This has several useful built-in check functions. You can also create your own custom functions and register them with your Validator object.
Each check is the name of one of these functions, including any parameters and keyword arguments. The configspecs look like function calls, and they map to function calls.
The basic datatypes that an un-extended Validator can test for are :
It can also handle lists of these types and restrict a value to being one from a set of options.
An example configspec is going to look something like :
port = integer(0, 100) user = string(max=25) mode = option('quiet', 'loud', 'silent')
You can specify default values, and also have the same configspec applied to several sections. This is called repeated sections.
For full details on writing configspecs, please refer to the validate.py documentation.
Important
Your configspec is read by ConfigObj in the same way as a config file.
That means you can do interpolation within your configspec.
In order to allow this, checks in the 'DEFAULT' section (of the root level of your configspec) are not used.
By default, validation does type conversion. This means that if you specify integer as the check, then calling validate will actually change the value to an integer (so long as the check succeeds).
It also means that when you call the write method, the value will be converted back into a string using the str function.
To switch this off, and leave values as strings after validation, you need to set the stringify attribute to False. If this is the case, attempting to set a value to a non-string will raise an error.
You can set a default value in your check. If the value is missing from the config file then this value will be used instead. This means that your user only has to supply values that differ from the defaults.
If you don't supply a default then for a value to be missing is an error, and this will show in the return value from validate.
Additionally you can set the default to be None. This means the value will be set to None (the object) whichever check is used. (It will be set to '' rather than None if stringify is False). You can use this to easily implement optional values in your config files.
port = integer(0, 100, default=80) user = string(max=25, default=0) mode = option('quiet', 'loud', 'silent', default='loud') nick = string(default=None)
Note
Because the default goes through type conversion, it also has to pass the check.
Note that default=None is case sensitive.
It's possible that you will want to specify a list as a default value. To avoid confusing syntax with commas and quotes you use a list constructor to specify that keyword arguments are lists. This includes the default value. This makes checks look something like :
checkname(default=list('val1', 'val2', 'val3'))
This works with all keyword arguments, but is most useful for default values.
Repeated sections are a way of specifying a configspec for a section that should be applied to all subsections in the same section.
The easiest way of explaining this is to give an example. Suppose you have a config file that describes a dog. That dog has various attributes, but it can also have many fleas. You don't know in advance how many fleas there will be, or what they will be called, but you want each flea validated against the same configspec.
We can define a section called fleas. We want every flea in that section (every sub-section) to have the same configspec applied to it. We do this by defining a single section called __many__.
[dog] name = string(default=Rover) age = float(0, 99, default=0) [[fleas]] [[[__many__]]] bloodsucker = boolean(default=True) children = integer(default=10000) size = option(small, tiny, micro, default=tiny)
Every flea on our dog will now be validated using the __many__ configspec.
If you define another sub-section in a section as well as a __many__ then you will get an error.
__many__ sections can have sub-sections, including their own __many__ sub-sections. Defaults work in the normal way in repeated sections.
String interpolation and validation don't play well together. When validation changes type it sets the value. If the value uses interpolation, then the interpolation reference would normally be overwritten. Calling write would then use the absolute value and the interpolation reference would be lost.
As a compromise - if the value is unchanged by validation then it is not reset.
This means strings that pass through validation unmodified will not be
overwritten. If validation changes type - the value has to be overwritten, and
any interpolation references are lost .
You may not need a full validation process, but still want to check if all the expected values are present.
Provided as part of the ConfigObj module is the SimpleVal object. This has a dummy test method that always passes.
The only reason a test will fail is if the value is missing. The return value from validate will either be True, meaning all present, or a dictionary with False for all missing values/sections.
To use it, you still need to pass in a valid configspec when you create the ConfigObj, but just set all the values to ''. Then create an instance of SimpleVal and pass it to the validate method.
As a trivial example if you had the following config file :
# config file for an application port = 80 protocol = http domain = voidspace top_level_domain = org.uk
You would write the following configspec :
port = '' protocol = '' domain = '' top_level_domain = ''
ConfigObj allows string interpolation similar to the way ConfigParser
You specify a value to be substituted by including %(name)s in the value.
Interpolation checks first the 'DEFAULT' sub-section of the current section to see if name is the key to a value. ('name' is case sensitive).
If it doesn't find it, next it checks the 'DEFAULT' section of the parent section, last it checks the 'DEFAULT' section of the main section.
If the value specified isn't found then a MissingInterpolationOption error is raised (a subclass of ConfigObjError).
If it is found then the returned value is also checked for substitutions. This allows you to make up compound values (for example directory paths) that use more than one default value. It also means it's possible to create circular references. If after ten replacements there are still values to substitute, an InterpolationDepthError is raised.
Both of these errors are subclasses of InterpolationError, which is a subclass of ConfigObjError.
String interpolation and validation don't play well together. This is because validation overwrites values - and so may erase the interpolation references. See Validation and Interpolation. (This can only happen if validation has to change the value).
Any line that starts with a '#', possibly preceded by whitespace, is a comment.
If a config file starts with comments then these are preserved as the initial_comment.
If a config file ends with comments then these are preserved as the final_comment.
Every key or section marker may have lines of comments immediately above it. These are saved as the comments attribute of the section. Each member is a list of lines.
You can also have a comment inline with a value. These are saved as the inline_comments attribute of the section, with one entry per member of the section.
Subsections (section markers in the config file) can also have comments.
See Section Attributes for more on these attributes.
These comments are all written back out by the write method.
ConfigObj 4 is designed to work with ASCII compatible encodings [14]. If you need support for other character sets, then I suggest you use the UTF8 encoding for your config files.
By default ConfigObj leaves keys/members as encoded byte strings (ordinary strings). If you want to access the config file members as Unicode objects rather than strings, you can use the decode method. This takes an encoding as its argument and decodes all members and keys into Unicode. It will only work if all members are byte strings (or lists of strings) , so you should do it before calling validate.
If you want to turn the Unicode strings back into byte strings, you can call the encode method. This also takes an encoding as its argument and assumes all keys/members are Unicode.
If you start working with Unicode strings, you may find you get UnicodeDecodeError or UnicodeEncodeError in unexpected places. This is because you have forced Python to do an implicit encode or decode.
Implicit decodes (and encodes) use the encoding returned by sys.getdefaultencoding(). This is usually ASCII. This means that if you have any non-ASCII characters, Python doesn't know how to treat them and will raise an error.
This happens if you add a byte string to a Unicode string, compare a byte string to a Unicode string, print a Unicode string, or write it to a file. If you work with Unicode, you should do the appropriate encode or decode first.
flatten_errors(cfg, res)
Validation is a powerful way of checking that the values supplied by the user make sense.
The validate method returns a results dictionary that represents pass or fail for each value. This doesn't give you any information about why the check failed.
flatten_errors is an example function that turns a results dictionary into a flat list, that only contains vaues that failed.
cfg is the ConfigObj instance being checked, res is the results dictionary returned by validate.
It returns a list of keys that failed. Each member of the list is a tuple :
([list of sections...], key, result)
If validate was called with preserve_errors=False (the default) then result will always be False.
list of sections is a flattened list of sections that the key was found in.
If the section was missing then key will be None.
If the value (or section) was missing then result will be False.
If validate was called with preserve_errors=True and a value was present, but failed the check, then result will be the exception object returned. You can use this as a string that describes the failure.
For example :
The value "3" is of the wrong type.
The output from flatten_errors is a list of tuples.
Here is an example of how you could present this information to the user.
There have been a lot of changes since ConfigObj 3. The core parser is now based on regular expressions, and is a lot faster and smaller. There is now no difference in the way we treat flat files and non-flatfiles, that is, no empty sections. This means some of the code can be a lot simpler, less code does more of the work [15].
There have been other simplifications: for example we only have eight options instead of seventeen.
Most config files created for ConfigObj 3 will be read with no changes and many programs will work without having to alter code. Some of the changes do break backwards compatibility: for example, code that uses the previous options will now raise an error. It should be very easy to fix these, though.
Below is a list of all the changes that affect backwards compatibility. This doesn't include details of method signatures that have changed, because almost all of them have.
(I have removed a lot of needless complications: this list is probably not conclusive, many option/attribute/method names have changed.)
Case sensitive.
The only valid divider is '='.
Line continuations with \ removed.
No recursive lists in values.
No empty sections.
No distinction between flatfiles and non flatfiles.
Change in list syntax: use commas to indicate list, not parentheses (square brackets and parentheses are no longer recognised as lists).
';' is no longer valid for comments, and no multiline comments.
No attribute-style access to values.
Empty values not allowed: use '' or "".
In ConfigObj 3, setting a non-flatfile member to None would initialise it as an empty section.
The escape entities '&mjf-lf;' and '&mjf-quot;' have gone, replaced by triple quote, multiple line values.
The newline, force_return, and default options have gone.
The encoding and backup_encoding methods have gone, replaced with the encode and decode methods.
fileerror and createempty options have become file_error and create_empty.
Partial configspecs (for specifying the order members should be written out, and which should be present) have gone. The configspec is no longer used to specify order for the write method.
Exceeding the maximum depth of recursion in string interpolation now raises an error InterpolationDepthError.
Specifying a value for interpolation which doesn't exist now raises a MissingInterpolationOption error (instead of merely being ignored).
The writein method has been removed.
The comments attribute is now a list (inline_comments equates to the old comments attribute).
ConfigObj 3 is now deprecated in favour of ConfigObj 4. I can fix bugs in ConfigObj 3 if needed, though.
For anyone who still needs it, you can download it here: ConfigObj 3.3.1
You can read the old docs at : ConfigObj 3 Docs
ConfigObj 4 is written by (and copyright) Michael Foord and Nicola Larosa.
Particularly thanks to Nicola Larosa for help on the config file spec, the validation system and the doctests.
validate.py was originally written by Michael Foord and Mark Andrews.
Thanks to others for input and bugfixes.
ConfigObj, and related files, are licensed under the BSD license. This is a
very unrestrictive license, but it comes with the usual disclaimer. This is
free software: test it, break it, just don't blame us if it eats your data !
Of course if it does, let us know and we'll fix the problem so it doesn't
happen to anyone else .
Copyright (c) 2004 & 2005, Michael Foord & Nicola Larosa All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Michael Foord nor Nicola Larosa may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
You should also be able to find a copy of this license at : BSD License
Fix any bugs (and resolvable issues).
Do an example for the 'walk' which removes uniform indentation in multiline values.
When initialising a section from a ConfigObj or an OrderedDictionary we could preserve ordering.
Add an odict method which returns an OrderedDictionary.
Note
Please file any bug reports to Michael Foord or the ConfigObj Mailing List.
You can't have a keyword with the same name as a section (in the same section). They are both dictionary keys, so they would overlap.
Interpolation checks first the 'DEFAULT' sub-section of the current section, next it checks the 'DEFAULT' section of the parent section, last it checks the 'DEFAULT' section of the main section.
Logically a 'DEFAULT' section should apply to all subsections of the same parent: this means that checking the 'DEFAULT' sub-section in the current section is not necessarily logical ?
In order to simplify Unicode support (which is possibly of limited value in a config file ?) I have removed automatic support, and added the encode and decode methods. These can be used to transform keys and entries. Because the regex looks for specific values on inital parsing (i.e. the quotes and the equals signs) it can only read ASCII compatible encodings. For Unicode I suggest UTF8, which is ASCII compatible.
Note
There is no reason why you shouldn't decode your config file into Unicode before passing them to ConfigObj (as a list of lines). This should give you Unicode keys and values.
Does it matter that we don't support the ':' divider, which is supported by ConfigParser ?
String interpolation and validation don't play well together. See Validation and Interpolation.
Validation is no longer done on the 'DEFAULT' section (on the root level). This allows interpolation from within your configspec - but also prevents you validating the 'DEFAULT' section.
This is an abbreviated changelog showing the major releases up to version 4. From version 4 it lists all releases and changes. More data on individual changes may be found in the source code.
Added merge, a recursive update.
Added preserve_errors to validate and the flatten_errors example function.
Thanks to Matthew Brett for suggestions and helping me iron out bugs.
Fixed bug where a config file is all comment, the comment will now be initial_comment rather than final_comment.
Validation no longer done on the 'DEFAULT' section (only in the root level). This allows interpolation in configspecs.
Also use the new list syntax in validate 0.2.1. (For configspecs).
Fixed bug in create_empty. Thanks to Paul Jimenez for the report.
Fixed bug in Section.walk when transforming names as well as values.
Added the istrue method. (Fetches the boolean equivalent of a string value).
Fixed list_values=False - they are now only quoted/unquoted if they are multiline values.
List values are written as item, item rather than item,item.
ConfigObj 4.0.0 Final
Fixed bug in setdefault. When creating a new section with setdefault the reference returned would be to the dictionary passed in not to the new section. Bug fixed and behaviour documented.
Obscure typo/bug fixed in write. Wouldn't have affected anyone though.
Removed PositionError.
Allowed quotes around keys as documented.
Fixed bug with commas in comments. (matched as a list value)
Fixed bug in __delitem__. Deleting an item no longer deletes the inline_comments attribute.
Fixed bug in initialising ConfigObj from a ConfigObj.
Changed the mailing list address.
Interpolation is switched off before writing out files.
Fixed bug in handling StringIO instances. (Thanks to report from "Gustavo Niemeyer" <gustavo@niemeyer.net>)
Moved the doctests from the __init__ method to a separate function. (For the sake of IDE calltips).
Reads nested subsections to any depth.
Multiline values.
Simplified options and methods.
New list syntax.
Faster, smaller, and better parser.
Validation greatly improved. Includes:
- type conversion
- default values
- repeated sections
Improved error handling.
Plus lots of other improvements .
Several incompatible changes: another major overhaul and change. (Lots of improvements though).
Added support for standard config files with sections. This has an entirely new interface: each section is a dictionary of values.
Changed the update method to be called writein: update clashes with a dict method.
Made various attributes keyword arguments, added several.
Configspecs and orderlists have changed a great deal.
Removed support for adding dictionaries: use update instead.
Now subclasses a new class called caselessDict. This should add various dictionary methods that could have caused errors before.
It also preserves the original casing of keywords when writing them back out.
Comments are also saved using a caselessDict.
Using a non-string key will now raise a TypeError rather than converting the key.
Added an exceptions keyword for much better handling of errors.
Made creatempty=False the default.
Now checks indict and any keyword args. Keyword args take precedence over indict.
' ', ':', '=', ',' and '\t' are now all valid dividers where the keyword is unquoted.
ConfigObj now does no type checking against configspec when you set items.
delete and add methods removed (they were unnecessary).
Docs rewritten to include all this gumph and more; actually ConfigObj is really easy to use.
Support for stdout was removed.
A few new methods added.
Charmap is now incorporated into ConfigObj.
Re-written it to subclass dict. My first forays into inheritance and operator overloading.
The config object now behaves like a dictionary.
This new version is much more 'classy'
It will also read straight from/to a filename and completely parse a config file without you having to supply a config spec.
Uses listparse, so can handle nested list items as values.
No longer has getval and setval methods: use normal dictionary methods, or add and delete.
Version 1.0.5 has a couple of bugfixes as well as a couple of useful additions over previous versions.
Since 1.0.0 the buildconfig function has been moved into this distribution, and the methods reset, verify, getval and setval have been added.
A couple of bugs have been fixed.
ConfigObj originated in a set of functions for reading config files in the atlantibots project. The original functions were written by Rob McNeur...
[1] | The core parser is now based on regular expressions, so it's a lot faster. |
[2] | 173 of them, at the time of writing. |
[3] | And if you discover any bugs, let us know. We'll fix them quickly. |
[4] | If you specify a filename that doesn't exist, ConfigObj will assume you are creating a new one. See the create_empty and file_error options. |
[5] | They can be byte strings ('ordinary' strings) or Unicode. If they are Unicode then ConfigObj will have to do an implicit encode before writing. See the encodings section for more details. |
[6] | Except we don't support the RFC822 style line continuations, nor ':' as a divider. |
[7] | For a file object that will depend what mode it was opened with. You can read and write to a StringIO instance, but not always to a cStringIO instance. |
[8] | A side effect of this is that it enables you to copy a ConfigObj : # only copies members # not attributes/comments config2 = ConfigObj(config1) The order of values and sections will not be preserved, though. |
[9] | Other than lists of strings. |
[10] | The method signature in the API docs will show that it does in fact take one argument: the section to be written. This is because the write method is called recursively. Using this argument forces write to return a list of lines, so it's probably not very useful to you. |
[11] | The dict method doesn't actually use the deepcopy mechanism. This means if you add nested lists (etc) to your ConfigObj, then the dictionary returned by dict may contain some references. For all normal ConfigObjs it will return a deepcopy. |
[12] | Passing (section, key) rather than (value, key) allows you to change the value by setting section[key] = newval. It also gives you access to the rename method of the section. |
[13] | Minimum required version of validate.py 0.2.0 . |
[14] | There's nothing to stop you decoding the whole config file to Unicode first. |
[15] | It also makes ConfigObj a lot simpler to use. |
Note
Rendering this document with docutils also needs the textmacros module and the PySrc CSS stuff. See http://www.voidspace.org.uk/python/firedrop2/textmacros.shtml