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, lemburg, loewis, vstinner
Date 2011-08-20.19:25:29
SpamBayes Score 0.0
Marked as misclassified No
Message-id <4E500A38.8090405@egenix.com>
In-reply-to <1313854240.58.0.391549455564.issue12794@psf.upfronthosting.co.za>
Content
STINNER Victor wrote:
> 
> New submission from STINNER Victor <victor.stinner@haypocalc.com>:
> 
> #12326 proposes to remove the major version from sys.platform. If we remove it, we will need another easy way to get this information. I don't think that we need the version used to build Python, but the version at runtime. That's why the platform is a good candidate to add such information.
> 
> I propose to add platform.major(): major version of the system, or 0 if we cannot get it. I chose 0 instead of None or raising an error to be consistent with the other functions. Platform functions don't raise error and always return the same type. For example, platform.release() returns an empty string if the release string cannot be read.
> 
> Each system formats its full version (e.g. (2, 6, 28) for Linux 2.6.28) differently. It is easier and more reliable to only provide the major version.
> 
> If you would like to get more information (e.g. minor minor), you have to test the system name. See for example platform.mac_ver(), platform.win_ver(), and also test.support.requires_linux_version().
> 
> Attached patch implements platform.major().

I'm not sure I understand why platform.release() isn't sufficient
for this purpose. Note that some systems return alphanumeric
values for platform.release(), e.g. for Windows you get
'NT' or 'XP'.

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

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

When Tarek was working on separating sysconfig from
distutils, we briefly discussed parsing the Makefile and pyconfig.h
files into a Python module. This would work around the issues
with the parsing overhead of using sysconfig and also prevent
the problems you currently find on some platforms that choose
to place the needed Makefile and pyconfig.h into a Python
development package.

However, even with those generated modules, access to the build
platform version would have to be provided through the sysconfig
module, not the platform module, since that's the more appropriate
module for such information.

That would be the full solution to the problem, but it would have
to go on a separate ticket.
History
Date User Action Args
2011-08-20 19:25:30lemburgsetrecipients: + lemburg, loewis, vstinner, Arfrever
2011-08-20 19:25:29lemburglinkissue12794 messages
2011-08-20 19:25:29lemburgcreate