Message142705
| Author |
vstinner |
| Recipients |
Arfrever, eric.araujo, lemburg, loewis, vstinner |
| Date |
2011年08月22日.08:54:34 |
| SpamBayes Score |
2.3176183e-09 |
| Marked as misclassified |
No |
| Message-id |
<4E521945.2070506@haypocalc.com> |
| In-reply-to |
<4E500A38.8090405@egenix.com> |
| Content |
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. |
|