Skip to main content

assert-python-definition-is-used

Assert that every public Python definition in a tree is named somewhere else.

Why

A function whose last caller is deleted does not disappear. Its tests still pass, the coverage gate over its module stays green, and static analysis keeps reading it, so the tree grows a layer of code that is maintained and never called. Nothing in a normal toolchain reports it: coverage measures whether lines run, not whether anything wants them, and a module held at 100% by its own tests manufactures exactly the evidence that makes it look used.

This tool asks the other question. For every public top-level def and class in the trees you point it at, it asks whether anything else names it, and reports the ones nothing does.

Installation

pip install assert-python-definition-is-used

Usage

# Every definition in lib/python must be named somewhere in the repo
assert-python-definition-is-used lib/python \
  --search-in lib/python --search-in scripts \
  --search-in src --search-in test

# The same, but a module's own tests no longer count as a caller
assert-python-definition-is-used lib/python \
  --search-in lib/python --search-in scripts \
  --search-in src --search-in test \
  --dont-search-in 'test/lib/python/test_{package}'

Those two runs are the pair worth having. The first is a cheap outer bound that catches a definition whose tests were deleted along with its caller. The second is the one that finds code kept alive only by the tests written for it, which is what a coverage gate hides.

Options

Option Effect
--search-in PATH A tree to search for uses. Repeatable.
--dont-search-in TEMPLATE Template left out of the search.
--exclude PATTERNS Comma-separated globs to leave out of both trees.
--quiet Print nothing; report through the exit code.
--count Print only how many findings there were.
--verbose Print the trees read, each file scanned, and a summary.
--fail-fast Stop at the first finding.
--warn-only Always exit 0.

Exit codes

Code Meaning
0 Nothing unused
1 Something unused
2 A tree was missing, unreadable, or would not parse

What counts as a use

A use is the definition's name written as a whole word in any file the searched trees reach, apart from the file the definition lives in. That is deliberately blunt, and it has consequences worth knowing before you read the output.

The file the definition lives in is read differently, because that file has already been parsed to find the definition in the first place. There a use has to be code that reads the name: a call, a decorator, a default, a base class, an annotation, or a parameter of that name, which is how a fixture is asked for. A function its own file calls is a helper doing its job, and reporting it would be wrong. The same word inside a docstring, a comment or an __all__ entry is prose about the definition rather than a use of it, and crediting that would leave a dead definition unreported. A def or class statement binds its name without reading it, so nothing counts as its own use.

Matching on a bare name in every other file means a definition reads as used when any other file happens to contain that word, including a file that defines its own unrelated function of the same name. The count is a lower bound rather than an exact figure.

Two dead functions in one file that call each other still read as used, because those calls are real code. Finding those needs reachability from a live entry point, which is a different tool.

Only top-level def and class statements are read. A method and a nested function are reached through the name of the thing that holds them, so neither is something this tool can speak about. Names starting with an underscore are skipped.

Packages and their own tests

The usual thing to leave out is a package's own tests, and --dont-search-in takes a path template rather than a fixed layout, because the convention differs between repositories. The {package} field is the first directory below the definition tree:

lib/python/aws_clients/__init__.py  ->  package is "aws_clients"

So --dont-search-in 'test/lib/python/test_{package}' leaves out test/lib/python/test_aws_clients/, and --dont-search-in 'test/lib/python/{package}' leaves out test/lib/python/aws_clients/.

A file sitting directly in the definition tree belongs to no package and so has no directory of its own to leave out. Uses of its definitions count wherever they appear.

--dont-search-in is not --exclude. An excluded file is dropped from the run altogether, so its own definitions go unchecked too. A file left out of the search is still read for the definitions it holds; it just does not get a vote on whether anything else is used.

GitHub Actions

- name: Assert every definition is used outside its own tests
  uses: 10U-Labs/assert-python-definition-is-used@latest
  with:
    dont-search-in: test/lib/python/test_{package}
    search-in: lib/python scripts src test
    trees: lib/python
    verbose: true

License

Apache-2.0

Metadata

Release files for assert-python-definition-is-used 20260823122013

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

Source distribution (sdist)

Source distribution for assert-python-definition-is-used 20260823122013
File Size Uploaded Provenance
assert_python_definition_is_used-20260823122013.tar.gz 33.3 kB With provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for assert-python-definition-is-used 20260823122013
File Interpreter ABI Platform
assert_python_definition_is_used-20260823122013-py3-none-any.whl Python 3 none any Details

Total release size: 48.8 kB

Release files / assert_python_definition_is_used-20260823122013.tar.gz

Download URL assert_python_definition_is_used-20260823122013.tar.gz
Size 33.3 kB
Tags Source
SHA-256 checksum
How to use checksums
d1536279b4cd987739895c4ccb46ad92259e69541e366ce06f24e8e3cebaf3cf
BLAKE2b-256 checksum
How to use checksums
b066100ac08daae0e7ec3ce7bda16e3dd0207930d0247381a4ee2887db7890a0
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

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 Aug 23, 2026.

Transparency log

Release files / assert_python_definition_is_used-20260823122013-py3-none-any.whl

Download URL assert_python_definition_is_used-20260823122013-py3-none-any.whl
Size 15.5 kB
Tags Python 3
SHA-256 checksum
How to use checksums
f6cedc45dcf0e0f608c13729b6f752c1b10bfa2d23ed6dd72b3afbf0aeba5bb9
BLAKE2b-256 checksum
How to use checksums
4a08b53182c97cd68b3e40d1c31d5622b8b9c80125adc86346398e5cfea68865
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

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 Aug 23, 2026.

Transparency log

Security for assert-python-definition-is-used 20260823122013

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.

Full provenance

All 2 files in this release have been uploaded with provenance metadata.

Select from 2 files

Attestation for assert_python_definition_is_used-20260823122013.tar.gz

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 Aug 23, 2026.

Transparency log

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

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