python-discovery can't locate the Python 3.7 interpreter (should be either fixed, or more clearly indicated as not supported)

[zzzeek]

hi -

As nox 2026.8.10 was just released now using python-discovery, a lot of new users are added to the project. so right up front it broke some of our CI builds that are still reaching back as far as Python 3.7.

Claude: With CPython 3.7.17 at /opt/python3.7/bin/python3.7, on PATH:

from python_discovery import get_interpreter
print(get_interpreter("3.7")) # None
print(get_interpreter("/opt/python3.7/bin/python3.7")) # RuntimeError
print(get_interpreter("3.9")) # works

The spec form returns None; the absolute-path form raises. Both share one cause,
visible at INFO/DEBUG:

DEBUG python_discovery._cached_py_info: get interpreter info via cmd:
 /opt/python3.7/bin/python3.7 .../python_discovery/_py_info.py <hash> <hash>
DEBUG python_discovery._cached_py_info: first subprocess attempt failed for
 /opt/python3.7/bin/python3.7 (failed to query ... with code 1 err:
 File ".../python_discovery/_py_info.py", line 183
 if (tk_lib := tcl.eval("set tk_library")) and os.path.isdir(tk_lib):
 ^
SyntaxError: invalid syntax
), retrying
INFO python_discovery._cached_py_info: failed to query /opt/python3.7/bin/python3.7 ...

It probes python3 and python3.7, twice each, fails identically every time, and
drops the candidate. get_interpreter("3.9") succeeds against
/opt/python3.9/bin/python3 in the same process, so PATH scanning itself is fine —
3.7 is the only version affected, since := is 3.8 syntax.

so the issue is due to a walrus operator in _py_info.py.

Now if this is not a bug, 3.7 is EOL for a long time and is simply not meant to run, great, I think the policy of when python-discovery as well as when nox drops EOL python versions should be more clearly stated. because 3.8, 3.9 are both EOL and 3.10 will be EOL in a few weeks too. if CI maintainers need to be pinning nox not just to the python version its being installed with, but also to the python versions our noxfiles are searching for, that's fine but as this is not straight packaging workflow i would want this to be made clear.

[zzzeek]

thanks for the quick fix!