[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