This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients Arfrever, eric.araujo, lemburg, loewis, vstinner
Date 2011-08-22.09:01:04
SpamBayes Score 1.3559601e-09
Marked as misclassified No
Message-id <4E521ACE.6000108@egenix.com>
In-reply-to <4E521945.2070506@haypocalc.com>
Content
STINNER Victor wrote:
> 
>> 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.

Ok, changed the title accordingly.

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

Well, it is important to somehow get the build information for
Python, since that tells us which OS features were available
at the time of compilation.

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

True, those two data points are different.
History
Date User Action Args
2011-08-22 09:01:05lemburgsetrecipients: + lemburg, loewis, vstinner, eric.araujo, Arfrever
2011-08-22 09:01:04lemburglinkissue12794 messages
2011-08-22 09:01:04lemburgcreate