> 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.