When the version is represented as 3.13t, the --python-version option needs an operand of 3.13, not 3.13t.
(This, and the fix here, will automatically apply to later threaded Pythons, such as 3.14t, too.)
Before this change, in the Python 3.13t run:
+ mypy --python-version=3.13t
usage: mypy [-h] [-v] [-V] [more options; see below]
[-m MODULE] [-p PACKAGE] [-c PROGRAM_TEXT] [files ...]
mypy: error: argument --python-version: Invalid python version '3.13t' (expected format: 'x.y')
This isn't new--it's always happened in the mypy step in the 3.13t job. We just never noticed it, because the mypy step always reports failure even when working correctly, because there are a number of unresolved type errors. Most of them should not be suppressed, but neither I nor others have get gotten around yet to fixing them. Some of them maybe should be suppressed, but neither I nor others have gotten around yet to verifying are reasonable to suppress. (For quite some time, the mypy step has step-level continue-on-error, which causes it not to fail the job.)
There's no connection between this and #2037 or #2038/#2039, except in the broad conceptual sense that this and #2038 share as a contributing factor that it's easy not to notice unanticipated new problems with mypy. However, just in case, I have verified that the effect of #2039 applies the same to 3.13t as to 3.13, by first testing this on a feature branch that had not integrated #2039, and then rebasing.
No change is needed in tox.ini, even separately from that not yet listing a py313t environment, because tox.ini as currently written does not pass a --python-version argument to mypy.
I plan to merge this once everything passes on CI, after also verifying again that the output is as expected.
Edit: The effect is as expected and intended. I'll just wait for the rest of CI to pass before merging.