Message136652
| Author |
vstinner |
| Recipients |
lemburg, neologix, pitrou, rosslagerwall, vstinner |
| Date |
2011年05月23日.14:51:21 |
| SpamBayes Score |
2.2815083e-14 |
| Marked as misclassified |
No |
| Message-id |
<1306162282.87.0.519444705144.issue12158@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> 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. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年05月23日 14:51:22 | vstinner | set | recipients:
+ vstinner, lemburg, pitrou, neologix, rosslagerwall |
| 2011年05月23日 14:51:22 | vstinner | set | messageid: <1306162282.87.0.519444705144.issue12158@psf.upfronthosting.co.za> |
| 2011年05月23日 14:51:22 | vstinner | link | issue12158 messages |
| 2011年05月23日 14:51:22 | vstinner | create |
|