[nicozdeb]

test_python_get_preferred_default fails on pre-release interpreters when there is no unversioned python executable on PATH.

In that case Python.get_active_python() finds nothing, so Python.get_preferred_python() falls back to Python.get_system_python(). That builds the version from sys.version_info[:3] and drops the pre-release suffix, which test_python_get_version_on_the_fly and test_python_get_system_python expect. Since #10518, the python_version fixture uses the full version from sys.version (e.g. 3.15.0rc1), so the assertion compares 3.15.0 with 3.15.0rc1 and fails.

The CI always has python on PATH, so this doesn't show up there. It does show up on the Debian build daemons, which only ship python3, during the Debian rebuild against the Python 3.15 release candidates (Debian bug #1147234).

The test now accepts either version, with a comment explaining why.

Checked on current main with Python 3.15.0rc1:

	no python on PATH	python on PATH
before	1 failed	passed
after	passed	passed

• Added tests for changed code. (test-only change)
• Updated documentation for changed code. (not needed)

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

Sourcery assessment

Approved.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

[nicozdeb]

pre-commit.ci autofix

[nicozdeb]

@radoering could you take a look when you have time? It's a follow-up to #10518: on systems without an unversioned python on PATH (e.g. Debian buildds) get_preferred_python() falls back to get_system_python(), which drops the pre-release suffix. Test-only change, CI is green. cc @hroncok since you hit the same test with rc releases in #10303/#10478.