homepage

Sometimes, we need to know the version of the Linux kernel. Recent examples: test if SOCK_CLOEXEC or O_CLOEXEC are supported by the kernel or not. Linux < 2.6.23 *silently* ignores O_CLOEXEC flag of open().
linux_version() is already implemented in test_socket, but it looks like test_posix does also need it.
Attached patch adds platform.linux_version(). It returns (a, b, c) (integers) or None (if not Linux).
It raises an error if the version string cannot be parsed.

STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner@haypocalc.com>:
> 
> Sometimes, we need to know the version of the Linux kernel. Recent examples: test if SOCK_CLOEXEC or O_CLOEXEC are supported by the kernel or not. Linux < 2.6.23 *silently* ignores O_CLOEXEC flag of open().
> 
> linux_version() is already implemented in test_socket, but it looks like test_posix does also need it.
> 
> Attached patch adds platform.linux_version(). It returns (a, b, c) (integers) or None (if not Linux).
> 
> It raises an error if the version string cannot be parsed.
The APIs in platform generally try not to raise errors, but instead
return a default value you pass in as parameter in case the
data cannot be fetched from the system.
The returned value should be a version string in a fixed
format, not a tuple. I'd suggest to use _norm_version()
for this.
Please also check whether this works on a few Linux systems.
I've checked it on openSUSE, Ubuntu.
Thanks,
-- 
Marc-Andre Lemburg
eGenix.com
________________________________________________________________________
2011年06月20日: EuroPython 2011, Florence, Italy 28 days to go
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
 eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
 Registered at Amtsgericht Duesseldorf: HRB 46611
 http://www.egenix.com/company/contact/ 

> The returned value should be a version string in a fixed format,
> not a tuple. I'd suggest to use _norm_version() for this.
How do you compare version strings? I prefer tuples, as sys.version_info, because the comparaison is more natural:
>>> '2.6.9' > '2.6.20'
True
>>> (2, 6, 9) > (2, 6, 20)
False

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
>> The returned value should be a version string in a fixed format,
>> not a tuple. I'd suggest to use _norm_version() for this.
> 
> How do you compare version strings? I prefer tuples, as sys.version_info, because the comparaison is more natural:
> 
>>>> '2.6.9' > '2.6.20'
> True
>>>> (2, 6, 9) > (2, 6, 20)
> False
The APIs are mostly used for creating textual representations
of system information, hence the use of strings.
You can add an additional linux_version_info() API if you want to
have tuples.

Use "%s.%s.%s" % linux_version() if you would like to format the version. The format is well defined. (You should only do that under Linux.)

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> Use "%s.%s.%s" % linux_version() if you would like to format the version. The format is well defined. (You should only do that under Linux.)
No, please follow the API conventions in that module and use a string.
You can then use linux_version().split('.') in code that want to
do version comparisons.
Thanks,
-- 
Marc-Andre Lemburg
eGenix.com
________________________________________________________________________
2011年06月20日: EuroPython 2011, Florence, Italy 28 days to go
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
 eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
 Registered at Amtsgericht Duesseldorf: HRB 46611
 http://www.egenix.com/company/contact/ 

Do we really need to expose a such Linux-centric and sparingly used
function to the platform module?
Since it's needed by several tests, why not add it to Lib/test/support.py?
That way, we could also make it return a tuple without breaking any
existing convention.

> 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
By the way, if you would like to *display* the Linux version, it's better to use release() which gives more information:
>>> 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.
Note: "info" suffix is not currently used, whereas there are python_version() and python_version_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.

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.

New changeset d585a6d548a3 by Victor Stinner in branch 'default':
Issue #12158: Move linux_version() from test_socket to test.support
http://hg.python.org/cpython/rev/d585a6d548a3