Infer `python_version` from `project.requires-python` when using pyproject.toml

[stephenfin]

Feature

Per the docs, the [mypy] python_version configuration option defaults to "the version of the Python interpreter used to run mypy." We should change this so that it is instead derived from the project.requires-python when the mypy configuration itself is defined in a pyproject.toml file, similar to what ruff currently does for ruff.target-version.

Pitch

Using the system Python version is almost always the wrong thing to do when running against a package that specifies a minimum supported Python version via their pyproject.toml file. This necessitates use of the [mypy] python_version option, even though it (perhaps partially) duplicates information already available. Automatically detecting a value for [mypy] python_version when not explicitly specified would be a neat little UX win.

[jorenham]

I thought that mypy defaulted to the runtime python version?

That can be useful when testing multiple python version in e.g. a CI testing matrix or tox.

[stephenfin]

I thought that mypy defaulted to the runtime python version?

It does. That's literally the first sentence of the issue 😅

That can be useful when testing multiple python version in e.g. a CI testing matrix or tox.

Is it? If your package supports e.g. Python 3.9 - 3.13 (i.e. all currently supported versions), is there a reason you'd want to test against > 3.9? fwict, all typing changes have been additive to date so there should be no reason for something that worked in an older version of Python to not work in a newer version.

(To be clear, you could always override the auto-detected version using the --python-version x.y opt or we could introduce a new option e.g. MYPY_PYTHON_VERSION that would be easily set in CI configurations, but I'm genuinely curious if using anything greater than the lowest Python version your package supports is beneficial).

[jorenham]

but I'm genuinely curious if using anything greater than the lowest Python version your package supports is beneficial

It can help if you have if sys.version_info >= ... blocks

[sterliakov]

Another story here is that ruff does not use the environment otherwise, so project.requires-python is a good source of information for them.

You shouldn't normally be running mypy installed system-wide, it should either be in the same venv as your dependencies (then everything is OK, python version is correct - same as what you're using), or you pass --python-executable of the venv'v python, then version of that should be used as default (not implemented now).

Could you explain why project.python-version should be the source of truth for mypy that is supposed to have a better one (an actual version of python)?

[stephenfin]

but I'm genuinely curious if using anything greater than the lowest Python version your package supports is beneficial

It can help if you have if sys.version_info >= ... blocks

Good point. But in that case, you probably want to run mypy multiple times, and as noted, you should be able to override the default with --python-version x.y.

[stephenfin]

Could you explain why project.python-version should be the source of truth for mypy that is supposed to have a better one (an actual version of python)?

I actually ran into the exact issue I'm hoping this would address again today:

sqlalchemy/dogpile.cache#278 (comment)

I used the new-style bar/pipe operator syntax for declaring a union, but the minimum version of Python used in that project is currently 3.9. mypy would have easily caught this for me had the Python version been inferred. Instead, mypy did not complain and instead things failed at runtime.

You shouldn't normally be running mypy installed system-wide, it should either be in the same venv as your dependencies (then everything is OK, python version is correct - same as what you're using), or you pass --python-executable of the venv'v python, then version of that should be used as default (not implemented now).

Understood. But that doesn't much help if I'm using mypy via a pre-commit hook, for example, or via an editor plugin. It also doesn't help if I do have a venv but my project supports multiple Python versions.

I should emphasise that I don't think we're changing much here. mypy already provides the [mypy] python_version option which overrides the version inferred from the environment, but which can in turn be overridden by the user setting the --python-version x.y opt. The use of project.python-version is simply another helpful default that would slot in between the [mypy] python_version-derived and environment-derived version.

[jorenham]

Good point. But in that case, you probably want to run mypy multiple times, and as noted, you should be able to override the default with --python-version x.y.

You're forgetting about stubtest.