Marc-Andre Lemburg <m...@egenix.com> added the comment:
STINNER Victor wrote:
>
> STINNER Victor <victor.stin...@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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12158>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
