configparser2 4.0.0

Why you’ll love configparser2

Whereas almost completely compatible with its older brother, configparser2 sports a bunch of interesting new features:

• full mapping protocol access (more info):

  >>> parser = ConfigParser()
  >>> parser.read_string("""
  [DEFAULT]
  location = upper left
  visible = yes
  editable = no
  color = blue
  
  [main]
  title = Main Menu
  color = green
  
  [options]
  title = Options
  """)
  >>> parser['main']['color']
  'green'
  >>> parser['main']['editable']
  'no'
  >>> section = parser['options']
  >>> section['title']
  'Options'
  >>> section['title'] = 'Options (editable: %(editable)s)'
  >>> section['title']
  'Options (editable: no)'

• there’s now one default ConfigParser class, which basically is the old SafeConfigParser with a bunch of tweaks which make it more predictable for users. Don’t need interpolation? Simply use ConfigParser(interpolation=None), no need to use a distinct RawConfigParser anymore.

• the parser is highly customizable upon instantiation supporting things like changing option delimiters, comment characters, the name of the DEFAULT section, the interpolation syntax, etc.

• you can easily create your own interpolation syntax but there are two powerful implementations built-in (more info):

  • the classic %(string-like)s syntax (called BasicInterpolation)

  • a new ${buildout:like} syntax (called ExtendedInterpolation)

• fallback values may be specified in getters (more info):

  >>> config.get('closet', 'monster',
  ...            fallback='No such things as monsters')
  'No such things as monsters'

• ConfigParser objects can now read data directly from strings and from dictionaries. That means importing configuration from JSON or specifying default values for the whole configuration (multiple sections) is now a single line of code. Same goes for copying data from another ConfigParser instance, thanks to its mapping protocol support.

• many smaller tweaks, updates and fixes

A few words about Unicode

configparser2 comes from Python 3 and as such it works well with Unicode. The library is generally cleaned up in terms of internal data storage and reading/writing files. There are a couple of incompatibilities with the old ConfigParser due to that. However, the work required to migrate is well worth it as it shows the issues that would likely come up during migration of your project to Python 3.

The design assumes that Unicode strings are used whenever possible [1]. That gives you the certainty that what’s stored in a configuration object is text. Once your configuration is read, the rest of your application doesn’t have to deal with encoding issues. All you have is text [2]. The only two phases when you should explicitly state encoding is when you either read from an external source (e.g. a file) or write back.

Versioning

This backport is intended to keep 100% compatibility with the vanilla release in Python 3.2+. To help maintaining a version you want and expect, a versioning scheme is used where:

• the first two numbers indicate the version of Python 3 from which the backport is done

• a backport release number is provided as the final number (zero-indexed)

For example, 3.5.2 is the third backport release of the configparser2 library as seen in Python 3.5. Note that 3.5.2 does NOT necessarily mean this backport version is based on the standard library of Python 3.5.2.

One exception from the 100% compatibility principle is that bugs fixed before releasing another minor Python 3 bugfix version will be included in the backport releases done in the mean time.

Maintenance

This backport is maintained on BitBucket by Łukasz Langa, the current vanilla configparser2 maintainer for CPython:

• configparser2 git repository

• configparser2 Mercurial repository

• configparser2 issue tracker

Change Log

Conversion Process

This section is technical and should bother you only if you are wondering how this backport is produced. If the implementation details of this backport are not important for you, feel free to ignore the following content.

configparser2 is converted using python-future and free time. Because a fully automatic conversion was not doable, I took the following branching approach:

• the 3.x branch holds unchanged files synchronized from the upstream CPython repository. The synchronization is currently done by manually copying the required files and stating from which CPython changeset they come from.

• the default branch holds a version of the 3.x code with some tweaks that make it independent from libraries and constructions unavailable on 2.x. Code on this branch still must work on the corresponding Python 3.x but will also work on Python 2.6 and 2.7 (including PyPy). You can check this running the supplied unit tests with tox.

The process works like this:

1. I update the 3.x branch with new versions of files. Commit.

2. I merge the new commit to default. I run tox. Commit.

3. If there are necessary changes, I do them now (on default). Note that the changes should be written in the syntax subset supported by Python 2.6.

4. I run tox. If it works, I update the docs and release the new version. Otherwise, I go back to point 3. I might use pasteurize to suggest me required changes but usually I do them manually to keep resulting code in a nicer form.

Footnotes