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):

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

configparser 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
configparser 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
configparser maintainer for CPython:

3.2.0r2

a backport-specific change: for convenience and basic compatibility with the
old ConfigParser, bytestrings are now accepted as section names, options and
values. Those strings are still converted to Unicode for internal storage so
in any case when such conversion is not possible (using the 'ascii' codec),
UnicodeDecodeError is raised.

3.2.0r1

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.

configparser 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:

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

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

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.

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

To somewhat ease migration, passing bytestrings is still supported but
they are converted to Unicode for internal storage anyway. This means
that for the vast majority of strings used in configuration files, it
won't matter if you pass them as bytestrings or Unicode. However, if you
pass a bytestring that cannot be converted to Unicode using the naive
ASCII codec, a UnicodeDecodeError will be raised. This is purposeful
and helps you manage proper encoding for all content you store in
memory, read from various sources and write back.

Life gets much easier when you understand that you basically manage
text in your application. You don't care about bytes but about
letters. In that regard the concept of content encoding is meaningless.
The only time when you deal with raw bytes is when you write the data to
a file. Then you have to specify how your text should be encoded. On
the other end, to get meaningful text from a file, the application
reading it has to know which encoding was used during its creation. But
once the bytes are read and properly decoded, all you have is text. This
is especially powerful when you start interacting with multiple data
sources. Even if each of them uses a different encoding, inside your
application data is held in abstract text form. You can program your
business logic without worrying about which data came from which source.
You can freely exchange the data you store between sources. Only
reading/writing files requires encoding your text to bytes.