Say How Each Measured Requirement Actually Fails

[ptr727]

Answers the suppressed finding on the promotion pull request #643, which cannot take a fix of its own since its head is develop.

The python3 tool's why text says older interpreters fail with an AttributeError "at the call rather than at startup", but spec/audit.py and scripts/pr_review.py now import UTC from datetime, which raises ImportError at import time on Python < 3.11.

Accepted. The sentence collapsed two requirements into one failure mode and was wrong for one of them. str.removeprefix is a method call and fails as the text described. datetime.UTC arrives through a module-level import:

$ grep -n "from datetime import" spec/audit.py scripts/pr_review.py scripts/test_pr_review.py
spec/audit.py:33:from datetime import UTC, datetime
scripts/pr_review.py:74:from datetime import UTC, datetime
scripts/test_pr_review.py:20:from datetime import UTC, datetime, timedelta

So on an older interpreter that module raises before any of it runs.

Constructed both failures rather than describing them, since the whole point of the sentence is to name the symptom a reader is looking at:

import-time  : ImportError -> cannot import name '...' from 'datetime'
call-time    : AttributeError -> 'str' object has no attribute 'removeprefix'

The entry now names each requirement with its own mode, and says the import failure is the one a host meets first, because the script does not start at all.

This matters more than a wording nit because of where the text is read. why is what scripts/host_gate.py prints to a host that just failed the floor. Telling that reader to expect an AttributeError partway through a run, when what they will actually see is an ImportError before anything runs, sends them looking for a different problem.

Verification

spec/validate.py exits 0, scripts/host_gate.py exits 0 reporting python3 3.13.5 meets the 3.13 floor, 552 tests pass, and prose_lint.py with the CI check list exits 0.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Updates the python3 entry in spec/host-tools.json to more accurately describe the concrete failure modes a host will see when running repository scripts on Python versions below specific standard-library feature floors.

Changes:

• Refines the python3.why text to distinguish import-time ImportError (for datetime.UTC on <3.11) from call-time AttributeError (for str.removeprefix/str.removesuffix on <3.9).
• Aligns the prose with the actual import sites in spec/audit.py, scripts/pr_review.py, and tests.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

spec/host-tools.json:53

• The why text says both str.removeprefix and str.removesuffix are called in scripts/prose_lint.py, but the repository only uses removeprefix there. removesuffix appears in spec/audit.py (e.g. s.removesuffix("|")), so the call-site list is currently inaccurate and could mislead someone debugging an older-interpreter failure.

            "why": "Every script here is standard library only, so a bare interpreter is enough and no package floor exists. The floor is the toolchain target rather than a measured breakage one version below it, which is the one entry here that reads that way and says so rather than implying a defect nobody found. pyproject.toml sets ruff target-version to py313 and mypy python_version to 3.13, so what those tools report describes 3.13 and describes no other interpreter, and a run below the floor is unverified rather than known broken. Neither tool runs in CI, which gates the standard-library script tests and the prose and repo gates and nothing else, so this floor is a configuration choice rather than an enforced result, and a host failing it has no CI failure to point at. Two hard requirements are measured, both sit lower, and they fail differently. str.removeprefix and str.removesuffix need 3.9 and are called in spec/audit.py and scripts/prose_lint.py, so an older interpreter starts, runs, and raises AttributeError when it reaches the call. datetime.UTC needs 3.11 and arrives through a module-level from datetime import UTC in spec/audit.py, scripts/pr_review.py and its tests, so an older interpreter raises ImportError before any of those modules run at all. Which mode a host sees is decided by the script it runs rather than by the interpreter alone: spec/audit.py carries both and fails at import, scripts/pr_review.py carries only the import and fails the same way, and scripts/prose_lint.py carries only the call and therefore starts, runs, and fails partway through. The name rather than the version is what differs per platform, which the second probe covers.",

[ptr727]

Answering the suppressed finding from the round on d2e51c9a. Fixed in 2abc6f4, along with one more that finding prompted me to go looking for.

The why text says both str.removeprefix and str.removesuffix are called in scripts/prose_lint.py, but the repository only uses removeprefix there.

Accepted. Enumerating per method rather than with one combined grep, which is exactly what produced the combined claim:

$ grep -n "\.removeprefix(" $(git ls-files '*.py')
scripts/prose_lint.py:91:    return path.as_posix().removeprefix('./')
spec/audit.py:714:    s = s.removeprefix("|")

$ grep -n "\.removesuffix(" $(git ls-files '*.py')
spec/audit.py:74:        return r.stdout.strip().rstrip("/").removesuffix(".git").split("/")[-1], True
spec/audit.py:715:    s = s.removesuffix("|")

The entry now names each method against the files that call it.

The audit that finding should have triggered four findings ago

This is the fifth correction to this one field, so instead of fixing the named sentence and pushing, I read every remaining claim in it against the tree. That found a sixth, which no review had reached:

Neither tool runs in CI, which gates the standard-library script tests and the prose and repo gates and nothing else

validate-task.yml also runs markdownlint, cspell, actionlint, editorconfig-checker and spec/validate.py. The point being made survives, that no Python linter or type checker runs in CI, and the "nothing else" did not. It now lists what CI actually runs.

The rest checked out. "Standard library only" was verified by walking every import in every tracked .py against sys.stdlib_module_names plus the local module names, with no third-party import found, rather than by trusting the sentence. The pyproject.toml settings, the three UTC import sites and the per-module failure modes each read as stated.

What kept going wrong

Six inaccuracies in one field, and every one has the same shape: a sentence generalising past what I had actually measured. Each measurement was one grep away, and the reason five of them reached review is that I corrected the sentence I was shown and never re-read its neighbours. The field's stated purpose, written above it in this same file, is to keep a floor from becoming folklore, and an unverified generalisation is how folklore gets written down.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.