Need clarification for marker version comparison operator

I’m a bit confused by this explanation in PEP 508, or PyPA specs

Comparisons in marker expressions are typed by the comparison operator. The <marker_op> operators that are not in <version_cmp> perform the same as they do for strings in Python. The <version_cmp> operators use the version comparison rules of the Version specifier specification when those are defined (that is when both sides have a valid version specifier). If there is no defined behaviour of this specification and the operator exists in Python, then the operator falls back to the Python behaviour. Otherwise an error should be raised. e.g. the following will result in errors:

"dog" ~= "fred"
python_version ~= "surprise"

With the statements and examples, it’s clear that when the right value is a non-version string, it SHOULD fail with an error. But if the left value is a non-version string, whether it is an error appears to have debatable room. See this example:

platform_release >= "6"

This is a completely normal environment marker, at least it should not fail at parse time. But what if the platform_release in the environment is a non-version string at evaluation time? You can think about it less and throw errors, which is completely in line with the PEP’s specification, as implemented by packaging. The problem is in the real world this can happen, in many Linux distros, the value of platform_release is not a version string, like this issue. This will cause those markers to reject evaluation completely. IMHO it should be better to just return False at evaluation, which means that the current platform doesn’t satisfy this constraint.

This is just my own thought. I’m posting here to discuss whether we can clarify this in the PEP, and then modify the implementation of packaging.

We have a <version_cmp> operator but we do not satisfy “both sides have a valid version specifier”.

So the spec’s answer is “the operator falls back to the Python behaviour”, no?

>= is a valid string comparison, I don’t follow why the result should be an error or always False.

Oh, thanks. I overlooked that line, so it is well covered by the spec but the implementation of packaging is incorrect