Pin ruff target-version to py310, and drop the future imports it made redundant

[David Harris (davidharrishmc)]

Two commits: a config fix, and the cleanup it enables.

1. Pin target-version = "py310"

[tool.ruff] sets line-length but never target-version, and the root pyproject.toml has no [project] table, so there is no requires-python for ruff to infer the target from either. Ruff falls back to searching outside the repository and picks up whatever the nearest ancestor Python project declares.

The result is that lint results depend on where the repository is checked out.

In a standalone checkout, as in CI, nothing is found, ruff's default applies, and the tree lints clean. But checked out inside another Python project that declares an older floor — which is how this repo is consumed when vendored as a submodule, e.g. under a parent that sets requires-python = ">=3.9" — ruff resolves py39 and reports 16 errors CI never sees, all of them FA102 (missing from __future__ import annotations, but uses PEP 604 union) on files that are correct for this project's actual floor.

Reproduced by forcing the version on an otherwise unmodified tree:

invocation	result
ruff check . (standalone, default)	clean
ruff check --target-version py39 .	16 errors
ruff check --target-version py310 .	clean

py310 is the floor this project already commits to everywhere else: [tool.pyright] sets pythonVersion = "3.10", all three workspace members declare requires-python = ">=3.10", AGENTS.md asks contributors to keep the Python 3.10-compatible, and CI rewrites .python-version to 3.10 for the oldest-supported-version job. Ruff was the one tool left inferring it. Note the asymmetry this removes — pyright was already immune, because its version is pinned in the same file.

This does not change CI results today. It makes them reproducible outside CI, and stable if ruff changes its default in a future release.

2. Drop from __future__ import annotations where it is now redundant

With the target pinned to py310, PEP 604 unions (X | Y) and PEP 585 builtin generics (list[int]) are natively valid in annotations. Removed from 40 files.

Three files genuinely still need it and keep it:

file	why
generators/testgen/src/testgen/data/registers.py	four methods annotated with classes not yet defined at that point (RegisterFile, IntegerRegisterFile, FloatRegisterFile, VectorRegisterFile) — NameError at import without lazy annotations
framework/src/act/parse_udb_config.py	imports act.config.Config under if TYPE_CHECKING:; eager annotations would force it to a runtime import
framework/src/act/build_cache.py	_new_hash() -> hashlib._Hash — that name exists only in typeshed, not at runtime

A note for future cleanups of this kind

The build_cache.py case is worth calling out. Python 3.14 implements PEP 649, so annotations are lazily evaluated by default there and this entire class of breakage is invisible on a 3.14 interpreter — the full ACT build passes. On the 3.10 floor it fails at import with AttributeError: module 'hashlib' has no attribute '_Hash'. Anyone repeating this cleanup should verify against 3.10, not against a modern local interpreter. This PR's first CI run caught exactly that, on the Python 3.10 (uv) job.

Verification

All re-run on Python 3.10, matching the oldest-supported-version CI job:

• ruff check and pyright clean; ruff format --check reports no change on any touched file. (One unrelated file is format-dirty on act4 already, before and after this change.)
• Every touched module imports — this is what catches eager-annotation errors that pyright cannot, since pyright assumes TYPE_CHECKING is true and trusts typeshed.
• make tests leaves the checked-in generated trees with zero diff.
• FAST=True EXTENSIONS=I make — the exact CI step that failed — completes a real build of 204 ELFs.

🤖 Generated with Claude Code