STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
>> You can then use linux_version().split('.') in code that want
>> to do version comparisons.
> 
> It doesn't give the expected result:
> 
>>>> ('2', '6', '9') < ('2', '6', '20')
> False
>>>> ('2', '6', '9') > ('2', '6', '20')
> True

Sorry, I forgot the tuple(int(x) for ...) part.

> By the way, if you would like to *display* the Linux version, it's better to use release() which gives more information:

No, release() doesn't have any defined format.

>>>> platform.linux_version()
> (2, 6, 38)
>>>> platform.release()
> '2.6.38-2-amd64'
> 
> About the name convention: mac_ver() and win32_ver() do return tuples. If you prefer linux_version_tuple(), it's as you want. But return a tuple of strings is useless: if you would like a string, use release() and parse the string yourself.

Please look again: they both return the version and other infos as
strings.

> Note: "info" suffix is not currently used, whereas there are python_version() and python_version_tuple().

Good point. I was thinking of the sys module function to
return the Python version as tuple.

>> Do we really need to expose a such Linux-centric and sparingly
>> used function to the platform module?
> 
> The platform module has already 2 functions specific to Linux: linux_distribution() and libc_ver(). But if my proposed API doesn't fit platform conventions, yeah, we can move the function to test.support.

Indeed and in retrospect, adding linux_distribution() was a mistake,
since it causes too much maintenance.

The linux_version() is likely going to cause similar issues, since
on the systems I checked, some return three part versions,
others four parts and then again other add a distribution specific
revision counter to it.

Then you have pre-releases, release candidates and development
versions:

http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering

Reconsidering, I think it's better not to add the API to prevent
opening up another can of worms.