fix and make common python version normalization

[dimbleby]

relating to python-poetry/poetry#5717

there were two similar but diverging bits of code. They really ought to be the same; and the version that I've gone for is actually not quite the same as either of the originals.

Specifically, in the handling of python_version when specified with either one or two digits...

First, the single digit case.

• I believe that a constraint like python_version > 3 is strictly not valid, PEP 508 says that the python_version should be equivalent to '.'.join(platform.python_version_tuple()[:2]).
• However experiment with pip and a requirements.txt teaches me that in my 3.8.10 environment, python_version > 3 does allow a dependency to be installed
• python_version <= "3" does not allow installation at 3.8.10
• So I conclude that the interpretation of >3 as > 3.0.0 per Fix an error when handling single digit Python markers #155 is reasonable, and have removed code that treats >3 as >=4.0.0

For the two digit case though, experiment shows that python_version > "3.8" does indeed cause pip not to install a dependency in my 3.8.10 environment, that I think should be reinterpreted as >=3.9.0. So I have included that code.

[neersighted]

I think that being bug/implementation compatible with Pip here is, unfortunately, the correct move. That being said, I would like to put a streamlined version of your testing/research in the docstring or comments as appropriate. Looks good to merge after that.

[dimbleby]

I added a comment.

I also went to the trouble of installing python 3.0.0, to see how single digit precision really works at the edge cases.

Turns out that python_version <= "3" is not satisfied, according to pip, at 3.0.0. I reckon that probably what's happening is that the strings "3" (from the marker) and "3.0" (from the actual python version) are compared, as strings.

So I've added a comment saying that, and updated the code accordingly (not that there's anyone out there running 2.0.0 or 3.0.0 who will ever care about the difference)

[dimbleby]

Hmm, not sure I appreciate sonarcloud telling me that it doesn't like this code, let's try a small rearrangement...

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[dimbleby]

Good luck to anyone who thinks they can make this function satisfy sonarcloud, I've suppressed the warning

[neersighted]

Hmm, not sure I appreciate sonarcloud telling me that it doesn't like this code, let's try a small rearrangement...

Honestly I find the SonarCloud-driven version to be more readable and cleaner :)

LGTM if suppressing Sonar is all we can do, despite the mild refactor.