sincewhen

Find out which Python version added each feature your code uses.

Point sincewhen at a file and it will tell you what's in there, when each piece of it arrived, and how old a Python you could get away with running it on.

Installation

Installing with uv tool:

uv tool install sincewhen

Installing with pipx:

pipx install sincewhen

You can also install sincewhen globally with pip, but I usually recommend installing command-line tools in their own separate environment.

Usage

Give sincewhen a file to see every dated feature it uses:

$ sincewhen example.py
example.py:1  tomllib module                  3.11  2022-10-24
example.py:3  positional-only parameters (/)  3.8   2019-10-14
example.py:4  with statement                  2.5   2006-09-19

Minimum: Python 3.11, released 2022-10-24 (set by tomllib module)

The last column is the day that release shipped, so a version number reads as an age.

Only the first use of each feature is shown by default. Pass --all to see every occurrence.

The dataset reaches back to Python 0.9.1, which means a file will report things like str() and open() that have been there since 1991. Pass --since to hide them:

$ sincewhen --since 3.0 example.py

Read from standard input with -:

$ echo 'x: int = 1' | sincewhen -
<stdin>:1  variable annotation  3.6  2016-12-23

Minimum: Python 3.6, released 2016-12-23 (set by variable annotation)

Look a single feature up by name instead of analyzing code:

$ sincewhen --search walrus
walrus operator (:=) - Python 3.8 (released 2019-10-14)
  PEP: https://peps.python.org/pep-0572/
  Docs: https://docs.python.org/3/whatsnew/3.8.html

Pass --json to either mode for machine-readable output.

Library

>>> import sincewhen
>>> sincewhen.minimum_version("import tomllib")
Version(major=3, minor=11)
>>> [d.feature.name for d in sincewhen.detect("if (n := 1): pass")]
['walrus operator (:=)']
>>> sincewhen.lookup("tomllib")[0].added
Version(major=3, minor=11)

Why it needs Python 3.14

sincewhen parses code with the standard library's ast module, which can only understand syntax that the running interpreter understands. A Python 3.9 interpreter cannot parse a match statement, so it could not report one either. Requiring the newest Python is what lets sincewhen recognize the newest syntax.

The Python version you run sincewhen on has nothing to do with the versions it reports on, which reach back to Python 0.9.1.

Known limits

• Some features are genuinely ambiguous in an AST. a | b could be a Python 3.9 dict merge, a Python 3.10 union type, or an integer bitwise-or that has worked since forever, and the AST alone cannot tell you which. Ambiguous features are left out rather than guessed at.
• Detection is syntactic. sincewhen sees that you called something named math.isclose, not that you called the real one. Shadowed builtins are skipped, but a shadowed module attribute is not.
• The dataset is curated and incomplete. A feature that isn't in it won't be reported, so the minimum version is a lower bound on the true answer.
• added is the oldest release from which a feature has been available ever since, ignoring Python 3.0 and 3.1. Nobody shipped code on those two, so a gap there is not a gap anyone lived through: argparse shipped in 2.7 and again in 3.2, and is dated 2.7. A feature missing from 3.2 as well has a real gap and takes the later date.
• Some features are older than the oldest surviving record, and are reported as "0.9 or earlier". Python 0.9.1, from 1991, is as far back as anything goes.
• Release dates come from python.org's downloads database back to 2.2, and from CPython's release tags before that. Python 0.9 and 1.6 have no release tag, so they show no date.
• Searching for a module member that has no entry of its own falls back to the module it lives in, since a member cannot be older than its module.

Development

This project uses uv and just. Run just to see every available task.

$ just test     # run the test suite
$ just check    # format, lint, typecheck, and test

No setup step is needed: uv creates the virtual environment and installs dependencies on the first uv run.

If you would rather not install just, every task is a short uv command that you can run directly (check the justfile for the commands):

uv run pytest

Adding a feature

Features live in src/sincewhen/features.toml, one [[features]] table each. Give the feature an id, a human-readable name, the version that added it, a category, exactly one matcher, and the evidence for the version:

[[features]]
id = "walrus"
name = "walrus operator (:=)"
added = "3.8"
category = "syntax"
pep = 572
nodes = ["NamedExpr"]

[features.evidence]
method = "pep"
pep = 572
python_version = "3.8"
checked = "2026-07-28"

The matcher kinds are nodes (AST node class names), builtins, modules, and attributes (dotted module.name paths). Node matchers can be narrowed with requires (a node attribute that must be truthy) or check (a predicate registered in detect.py).

Documentation links are generated from added and pep, so only set docs when you have a better link than the "What's New" page.

Nobody should be typing version numbers from memory. For anything in the standard library, let the archived documentation say what the version is:

$ just fetch-docs                       # one-time, ~500 MB into a gitignored .cache/
$ just whenadded math.lcm               # what each source says, and whether they agree
$ just propose math.lcm math.isqrt      # entries with evidence, ready to paste
$ just verify-dataset                   # re-derive every claim in the dataset

just verify-dataset also runs in CI, so a pull request that edits a version without editing its evidence fails.

Evidence has seven method values, six of which a machine can recheck:

manual is for the cases where the sources genuinely disagree, and every one of them is printed on every verify-dataset run so the override stays visible.

A new entry, or a corrected version on an existing one, also gets a line under Unreleased in CHANGELOG.md. Dataset changes are the ones that alter what sincewhen reports about code that did not change, so they are worth spelling out.

Releasing

Move the Unreleased notes in CHANGELOG.md under a heading for the new version, then bump, tag, and push:

$ just bump patch
$ just release

just release refuses to tag a version that the changelog has nothing to say about, so the notes have to be written before the release goes out rather than after.

Pushing a v* tag runs the release workflow, which publishes to PyPI with trusted publishing and creates a GitHub release whose notes are that version's changelog section.

License

sincewhen is distributed under the terms of the MIT license.