boltons: 230+ pure-Python utilities the standard library left out

What boltons solves, and who it is written for

The README opens with a claim that doubles as a scope statement: boltons should be builtins. The project is a set of over 230 BSD-licensed, pure-Python utilities described as being in the same spirit as the standard library and yet conspicuously missing from it. That framing tells you who it is for. If you write Python and keep reaching for the same small helpers, an ordered multidict, a chunked iterator, a retry with jitter, you are the intended reader.

The pitch is not a framework. Nothing in the README asks you to restructure an application around boltons. The description says the constructs extend and rely on nothing but the Python standard library, and the repository layout backs that up: a single boltons/ package, a tests/ directory, docs/, and a pyproject.toml whose build backend is flit_core. There is no dependency list to audit because there are no runtime dependencies to declare.

That matters most in constrained environments. A pure-Python package with no dependencies is easy to vendor into a codebase that cannot add transitive packages, and the README explicitly raises that option for application developers.

How boltons is organised: independent modules, not a monolith

The architecture is flat and module-per-concern. The README names fileutils, dictutils, queueutils, iterutils and tbutils, and each one carries a distinct set of tools. fileutils supplies atomic_save, described as atomic file saving bolted on. dictutils holds OrderedMultiDict, which the README calls highly optimized. queueutils provides two types of PriorityQueue. iterutils covers chunked and windowed iteration, recursive data structure iteration and merging through remap, and exponential backoff with jitter. tbutils offers a full-featured TracebackInfo type for representing stack traces.

The important design detail is that these modules do not depend on each other in a way that forces you to take the whole package. The README states that each module is independent and can be copied directly into a project, and it points to an Integration section of the docs for the details. So the realistic data flow is: you import one module, or you paste one file into your source tree, and nothing else from boltons comes along.

That is a deliberate trade-off. You get a small surface area and no version-coupling between the pieces you use and the pieces you do not. You also get no cross-module convenience layer, because there is not supposed to be one.

Installing boltons and a first real use

The README gives the obvious install path first. The package is on PyPI, so a normal pip install brings it in.

pip install boltons

On macOS, the README documents a second route through MacPorts:

sudo port install py-boltons

After installing, the README says dozens of boltons are just an import away, and gives this example of an LRU cache:

from boltons.cacheutils import LRU
my_cache = LRU()

That is the whole first use: import the class, instantiate it, and use it as a cache. Nothing else is required, and no configuration file or environment variable appears in the README.

If you would rather not take the dependency at all, the README describes the alternative: because boltons is pure-Python with no dependencies, individual modules can be copied into a project, with the docs' Integration section covering the mechanics. For a first evaluation, the pip route is the shorter path; vendoring is the option you consider once you know which one or two modules you actually want.

Where boltons deliberately stops short

The README is unusually candid about the ceiling. It states that the majority of boltons strive to be good enough for a wide range of basic uses, leaving advanced use cases to Python's specialised third-party libraries. In many cases the module documentation itself will point to alternatives worth investigating when a use case outgrows boltons.

Read that as a boundary rather than a defect. An OrderedMultiDict that is good enough for ordinary lookups is not a substitute for a data structure tuned for a specific access pattern under heavy load. The two PriorityQueue types in queueutils are not a distributed task queue. If your problem has a well-known specialist library, boltons is not trying to displace it, and the README says so.

The other limitation is structural. A collection of small utilities has no single owner of your problem. If iterutils.remap does not do what you need, there is no larger framework to fall back on inside the project; you either extend it yourself or move to a dedicated library. The README's Gaps section invites feature requests and pull requests, but it also asks you to read the architecture statement first to check whether the functionality would be a good fit. That gate exists precisely because the project does not want to absorb everything.

boltons against a general-purpose utility toolkit

The natural comparison is with a broad utility library such as Toolz, or with a general-purpose package like more-itertools. The difference is in packaging philosophy rather than in any single function.

boltons is organised so that each module stands alone and can be copied into a project, which the README states directly. That makes it viable in a codebase where adding a dependency is expensive, because you can take fileutils without taking queueutils. A toolkit that expects to be installed as a whole asks you to accept its full surface area and its release cadence along with the one helper you wanted.

The second difference is the stated ambition level. boltons aims to be good enough for basic uses and defers to specialised libraries beyond that, per the README. Some toolkits aim to be the general answer. Which is better depends on whether you want a small set of pieces you can lift out, or a single dependency you can lean on for a wide range of work.

Maintenance, versioning and licence questions

The repository is not archived, and the most recent push recorded for it is 2026-09-08. Releases follow CalVer in the YY.MINOR.MICRO form, and the recent tags run 26.0.0, 26.1.0 and 26.2.0 across June, July and September of 2026. The README states that boltons is tested against Python 3.7 through 3.14, as well as PyPy3, and pyproject.toml sets requires-python to >=3.7 with classifiers covering the same range.

That breadth has a cost you should plan for. Supporting 3.7 through 3.14 constrains what the code can use, so you should not expect the newest language features to appear in boltons modules. The development workflow in the README uses uv: create a virtual environment and install in editable mode with uv venv && uv pip install -e ., then run the suite, which includes doctests, through tox with uvx --with tox-uv tox -e py314, or run all environments in parallel with uvx --with tox-uv tox -p auto.

On licensing, the signals do not line up. The README calls boltons BSD-licensed, and pyproject.toml carries the classifier License :: OSI Approved :: BSD License with license = { file = "LICENSE" }, but the repository metadata reports NOASSERTION. Read the LICENSE file in the repository before you depend on the terms; nothing here is legal advice.

Editorial conclusion

Adopt boltons if you want small, dependency-free helpers you can vendor one module at a time, and if Python 3.7 to 3.14 coverage plus PyPy3 matters to you. Do not adopt it expecting a full framework, heavy third-party integration, or a dedicated support team; the README positions most modules as good enough for basic uses and points elsewhere when needs grow. Before you rely on it, check the LICENSE file, because the repository metadata reports NOASSERTION while the README and the package classifiers both say BSD, and confirm whether you are installing from PyPI or copying a module into your tree.

Frequently asked questions

Official sources

1. Issues
2. mahmoud/boltons on GitHub
3. Project website
4. README
5. Releases