Package: configparser
This package is a backport of the refreshed and enhanced ConfigParser from
later Python versions. To use the backport instead of the built-in version,
simply import it explicitly as a backport:from backports import configparserTo use the backport on Python 2 and the built-in version on
Python 3, use the standard invocation:import configparserFor detailed documentation consult the vanilla version athttp://docs.python.org/3/library/configparser.html.Why you’ll loveconfigparserWhereas almost completely compatible with its older brother,configparsersports 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 defaultConfigParserclass, which basically is the oldSafeConfigParserwith a bunch of tweaks which make it more predictable for
users. Don’t need interpolation? Simply useConfigParser(interpolation=None), no need to use a distinctRawConfigParseranymore.the parser is highlycustomizable upon instantiationsupporting 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)ssyntax (calledBasicInterpolation)a new${buildout:like}syntax (calledExtendedInterpolation)fallback values may be specified in getters (more info):>>> config.get('closet', 'monster',
...            fallback='No such things as monsters')
'No such things as monsters'ConfigParserobjects can now read data directlyfrom stringsandfrom 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 anotherConfigParserinstance, thanks to its
mapping protocol support.many smaller tweaks, updates and fixesA few words about Unicodeconfigparsercomes 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 oldConfigParserdue 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.VersioningThis project usessemverto
communicate the impact of various releases while periodically syncing
with the upstream implementation in CPython.
Thehistoryserves as a reference indicating which versions incorporate
which upstream functionality.Prior to the4.0.0release,another schemewas used to associate the CPython and backports releases.MaintenanceThis backport was originally authored by Łukasz Langa, the current vanillaconfigparsermaintainer for CPython and is currently maintained by
Jason R. Coombs:configparser repositoryconfigparser issue trackerConversion ProcessThis 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.The project takes the following branching approach:The3.xbranch 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.Themainbranch holds a version of the3.xcode with some tweaks
that make it compatible with older Pythons. Code on this branch must work
on all supported Python versions. Test withtoxor in CI.The process works like this:In the3.xbranch, runpip-run--sync-upstream.py, which
downloads the latest stable release of Python and copies the relevant
files from there into their new locations and then commits those
changes with a nice reference to the relevant upstream commit hash.Check for new names in__all__and update imports inconfigparser.pyaccordingly. Commit.Merge the new commit tomain. Run tests. Commit.Make any compatibility changes onmain. Run tests. Commit.Update the docs and release the new version.Footnotes[1]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, aUnicodeDecodeErrorwill 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.[2]Life gets much easier when you understand that you basically managetextin 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.For EnterpriseAvailable as part of the Tidelift Subscription.This project and the maintainers of thousands of other packages are working with Tidelift to deliver one enterprise subscription that covers all of the open source you use.Learn more.