Compatible-release requires-python constraints infer unsupported targets

Open
  • Is something wrong?
#5,468 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@harisawan-bit is already working on this.

Since Jul 28, 2026.

  • #5269 by @harisawan-bit — open
  • #5469 by @maple-pwn — closed without merging
  • #5578 by @beniamin-levin — open
  • #5640 by @voidstackloop — open

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
tooling

Research direction

Start with black.files.infer_target_version and the strip_specifier_set behavior described in the report. Run the provided Python reproduction and inspect the existing target-version tests before adding regression coverage for patch-release compatible constraints. Done means ~=3.11.0 infers only PY311 while the existing two-component behavior remains unchanged.

Written by the indexing model from the issue text.

Description

Describe the bug

Target-version inference widens a compatible-release constraint when it removes the patch component. requires-python = "~=3.11.0" permits Python 3.11 releases, but Black infers Python 3.11 through 3.15 on current main.

To Reproduce

Create pyproject.toml:

[project]
requires-python = "~=3.11.0"

Run:

black --verbose --config pyproject.toml --code 'x=1'

The verbose configuration includes:

target_version: ['py311', 'py312', 'py313', 'py314', 'py315']

This can also be reproduced without formatting a file:

from black.files import infer_target_version

print([v.name for v in infer_target_version(
    {"project": {"requires-python": "~=3.11.0"}}
)])
# ['PY311', 'PY312', 'PY313', 'PY314', 'PY315']

Expected behavior

Only py311 should be inferred. The compatible-release specification preserves the prefix before the final release component: ~=3.11.0 is equivalent to >=3.11.0, ==3.11.*. In contrast, ~=3.11 permits later Python 3 minor versions.

Environment

  • Black: source checkout of main, commit 994ef7eeb18172178552daa1f36f001d156ad583, installed editable in a clean virtual environment.
  • CPython 3.14.6, macOS arm64.
  • packaging 26.3.

Additional context

strip_specifier_set turns ~=3.11.0 into ~=3.11, which loses the upper bound. ~=3.11.7 has the same problem. A focused fix can preserve the matching minor-version prefix while retaining the existing treatment of two-component constraints.

Related: #3581 discusses the strict-> lower-bound case; the broader rewrite in #3583 is closed. This report isolates the compatible-release upper-bound case. I have a small patch with regression coverage for patch releases, prereleases, additional release components, exclusions, and the distinct two-component form.

AI assistance: OpenAI Codex helped prepare the reproduction, patch, tests, and report. The outputs above were verified by execution locally.

Dominant language
Python
Stars
42.2k
Forks
3k
Avg merge
2d 14h
Merged PRs (30d)
98

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from psf/black

All issues in psf/black

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.