STINNER Victor <victor.stin...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue12794> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com