[qodelicious]

PythonSpec.satisfies skips a specifier item when the candidate has fewer version parts than the item needs. That makes sense for 3.12 against >=3.12.5, since the micro is unknown. But the needed precision came from len(item.version.release), and SimpleVersion always pads release to three parts. So every item counted as needing a micro, and any spec with only a major and minor passed every specifier.

from python_discovery import PythonSpec

PythonSpec.from_string_spec("3.11").satisfies(PythonSpec.from_string_spec(">=3.13"))  # True on main
PythonSpec.from_string_spec("3.14").satisfies(PythonSpec.from_string_spec("<3.13"))  # True on main
PythonSpec.from_string_spec("3.11").satisfies(PythonSpec.from_string_spec("==3.12.*"))  # True on main

This is what the Windows PEP 514 pre-filter in _windows/_propose.py uses. Registry entries only carry a major and minor, so with a specifier like >=3.13 the pre-filter let every registered CPython through and each one got spawned to collect its info, only to be rejected by PythonInfo.satisfies later.

The precision now comes from the parts the specifier was written with (the wildcard precision for ==3.12.*, and the pre-release suffix is ignored, the same way PythonInfo._satisfies_version_specifier counts them). The candidate is also cut to that precision before the check, matching PythonInfo.satisfies, so 3.12.1 satisfies ==3.12 in both places now. A candidate with fewer parts than the specifier still skips it, as before.

The old test_get_required_precision_attribute_error test only covered the AttributeError path on item.version.release, which is gone, so I replaced it with tests for the new precision and for satisfies at minor precision. They fail on main and pass here.