Issue12158
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2011-05-23 12:25 by vstinner, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
platform_linux_version.patch | vstinner, 2011-05-23 12:25 | review |
Messages (10) | |||
---|---|---|---|
msg136621 - (view) | Author: STINNER Victor (vstinner) * | Date: 2011-05-23 12:25 | |
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. |
|||
msg136625 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2011-05-23 13:02 | |
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/ |
|||
msg136626 - (view) | Author: STINNER Victor (vstinner) * | Date: 2011-05-23 13:06 | |
> 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 |
|||
msg136627 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2011-05-23 13:11 | |
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. |
|||
msg136632 - (view) | Author: STINNER Victor (vstinner) * | Date: 2011-05-23 13:27 | |
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.) |
|||
msg136633 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2011-05-23 13:30 | |
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/ |
|||
msg136638 - (view) | Author: Charles-François Natali (neologix) * | Date: 2011-05-23 13:59 | |
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. |
|||
msg136652 - (view) | Author: STINNER Victor (vstinner) * | Date: 2011-05-23 14:51 | |
> 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. |
|||
msg136678 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2011-05-23 16:40 | |
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. |
|||
msg136706 - (view) | Author: Roundup Robot (python-dev) | Date: 2011-05-23 22:24 | |
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 |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:57:17 | admin | set | github: 56367 |
2011-05-23 22:24:25 | python-dev | set | nosy:
+ python-dev messages: + msg136706 |
2011-05-23 16:41:03 | lemburg | set | status: open -> closed resolution: rejected |
2011-05-23 16:40:25 | lemburg | set | messages: + msg136678 |
2011-05-23 14:51:22 | vstinner | set | messages: + msg136652 |
2011-05-23 13:59:09 | neologix | set | messages: + msg136638 |
2011-05-23 13:30:13 | lemburg | set | messages: + msg136633 |
2011-05-23 13:27:35 | vstinner | set | messages: + msg136632 |
2011-05-23 13:11:26 | lemburg | set | messages: + msg136627 |
2011-05-23 13:06:06 | vstinner | set | messages: + msg136626 |
2011-05-23 13:02:56 | lemburg | set | messages: + msg136625 |
2011-05-23 12:27:17 | rosslagerwall | set | nosy:
+ rosslagerwall |
2011-05-23 12:25:26 | vstinner | create |