Skip to main content

imperfect

This is a module for making automated edits to an existing configparser-compatible ini file. It operates like a CST, parsing into a tree of nodes which can then be edited and written back, preserving whitespace and comments.

Quick Start

(Tested as test_example_from_readme in the test suite)

Let's say you have the following in setup.cfg:

[metadata]
# the package name
name = imperfect
# slurp the readme
long_description = file: README.md

[options]
packages = imperfect

and you'd like to make an edit setting long_description_content_type in [metadata] but don't care where it goes. Default is at the end of the section.

import imperfect
import io
with open("setup.cfg") as f:
    data = f.read()

conf: imperfect.ConfigFile = imperfect.parse_string(data)
conf.set_value("metadata", "long_description_content_type", "text/markdown")

print(conf.text)

What if you want to have control over the odering, and want it right before long_description? Now with diffing and more internals...

import moreorless
import imperfect
import io
with open("setup.cfg") as f:
    data = f.read()

conf: imperfect.ConfigFile = imperfect.parse_string(data)
metadata_section = conf["metadata"]

# Ignoring some whitespace for now, this looks like
# long_description_content_type =  text/markdown\n
# [                   entry                      ]
# [            key            ][eq][    value    ]

value = imperfect.ValueLine(
    whitespace_before_text='',
    text='text/markdown',
    whitespace_after_text='',
    newline='\n',
)
new_entry = imperfect.ConfigEntry(
    key="long_description_content_type",
    whitespace_before_equals=" ",
    equals="=",
    whitespace_before_value="  ",
    value = [value],
)
try:
    pos = metadata_section.index("long_description")
except KeyError:
    pos = len(metadata_section.entries)

metadata_section.entries.insert(pos, new_entry)

print(moreorless.unified_diff(data, conf.text, "config.cfg"), end="")
with open("setup.cfg", "w") as f:
    f.write(conf.text)
# or
with open("setup.cfg", "w") as f:
    conf.build(f)

A note on whitespace

Following the convention used by configobj, whitespace generally is accumulated and stored on the node that follows it. This does reasonably well for adding entries, but can have unexpected consequences when removing them. For example,

[section1]
# this belongs to k1
k1 = foo
# this belongs to k2
k2 = foo
# k3 = foo (actually belongs to the following section)

[section2]

An insertion to the end of section1 would go between k2 and the k3 comment. Removing section2 would also remove the commented-out k3.

I'm open to ideas that improve this.

A note on formats

The goal is to be as compatible as possible with RawConfigParser, which includes keeping some odd behaviors that are bugs that have been around for a decade and probably can't be changed now.

  1. Section names are very lenient. [[x]]yy is a legal section line, and the resulting section name is [x. The yy here is always allowed (we keep it in the tree though), even with inline_comments off.
  2. \r (carriage return) is considered a whitespace, but not a line terminator. This is a difference in behavior between str.splitlines(True) and list(io) -- configparser uses the latter.
  3. \t counts as single whitespace.

Supported parse options

Option                 Default  Imperfect supports
allow_no_value         False    only False
delimiters             =,:      only =,:
comment_prefixes       #,;      only #,;
empty_lines_in_values  True     True (False is very close to working)

Testing

We use hypothesis to generate plausible ini files and for all the ones that RawConfigParser can accept, we test that we accept, have the same keys/values, and can roundtrip it.

This currently happens in text mode only.

If you would like to test support on your file, try python -m imperfect.verify <filename>

Why not...

  • configobj has a completely different method for line continuations
  • I'm not aware of others with the goal of preserving whitespace

Version Compat

Usage of this library should work back to 3.7, but development (and mypy compatibility) only on 3.10-3.12. Linting requires 3.12 for full fidelity.

Versioning

This library follows meanver which basically means semver along with a promise to rename when the major version changes.

License

imperfect is copyright Tim Hatch, and licensed under the MIT license. See the LICENSE file for details.

Metadata

Release files for imperfect 0.4.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for imperfect 0.4.0
File Size Uploaded
imperfect-0.4.0.tar.gz 16.8 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for imperfect 0.4.0
File Interpreter ABI Platform
imperfect-0.4.0-py3-none-any.whl Python 3 none any Details

Total release size: 31.2 kB

Release files / imperfect-0.4.0.tar.gz

Download URL imperfect-0.4.0.tar.gz
Size 16.8 kB
Tags Source
SHA-256 checksum
How to use checksums
1606e5c3c0dfecc4802148125d48a6b18d69066c55b3dde1c051b142ea30214d
BLAKE2b-256 checksum
How to use checksums
72fbaa71349a5212ed09aa4dabf6e764d446d5665ca288922fdccc6f79f52528
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.12.9

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Apr 24, 2025.

Transparency log

Release files / imperfect-0.4.0-py3-none-any.whl

Download URL imperfect-0.4.0-py3-none-any.whl
Size 14.4 kB
Tags Python 3
SHA-256 checksum
How to use checksums
d4bf063486bf18eb2e71bfafe87e3341f81413a6662454072d187e27cca4002f
BLAKE2b-256 checksum
How to use checksums
10ffaeef41e291bb54db4e5277674dcd8db99be0e457c19fd49794617a5aad82
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/6.1.0 CPython/3.12.9

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Apr 24, 2025.

Transparency log

Release history Release notifications | RSS feed

This release

0.4.0 This release

2 release files

0.3.0

2 release files

0.2.0

2 release files

0.1.1

2 release files

0.1.0

2 release files

0.0.3

2 release files

0.0.2

2 release files

0.0.1

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page