[issue12794] platform: add a major function to get the system major version

STINNER Victor report at bugs.python.org
Mon Aug 22 10:54:41 CEST 2011


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Le 20/08/2011 21:25, Marc-Andre Lemburg a écrit :
> I'm not sure I understand why platform.release() isn't sufficient
> for this purpose.

You cannot write platform.release() >= (2, 28)  (Linux >= 2.28) or 
platform.release() >= 7  (FreeBSD 7 or later).

You may use int(platform.release()[0]) but it will fail after the major 
version 10, and I'm not sure that release() always starts with a digit.

> What we could do is add a function that tries to find out the
> true version number of the OS, e.g. for Windows 7 that would
> be (6, 1, 7601) instead of the marketing name '7' returned by
> platform.release().

Yes, it would be more pratical than release() and it would be possible 
to compare it using a tuple, like sys.version_info.

> Still, this won't help with the OS version used for the Python
> build.

I don't care of the OS version used to build. See my patch attached to 
#12795: only the version at runtime is important. The common use case is 
to check if the OS has a feature using its version, so the version at 
runtime.

> When Tarek was working on separating sysconfig from
> distutils, we briefly discussed parsing the Makefile and pyconfig.h
> files into a Python module.

This is now an issue: #9878. But it doesn't help if I need the version 
at runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12794>
_______________________________________


More information about the Python-bugs-list mailing list