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, ezio.melotti, lemburg, loewis, nadeem.vawda, vstinner
Date 2011-08-22.08:57:01
SpamBayes Score 6.661338e-15
Marked as misclassified No
Message-id <1314003422.81.0.170611517188.issue12795@psf.upfronthosting.co.za>
In-reply-to
Content
Moved the discussion here from issue12326:

>> [Larry Hastings]
>> >> If we're changing "linux2" / "linux3" to just "linux", we should be
>> >> consistent and do it for everybody.  I propose sys.platform under 3.3
>> >> should contain things like "linux", "freebsd", "openbsd", "darwin",
>> >> and "windows".

> [Martin v. Löwis]
> > Definitely not. The reasoning that applies to Linux doesn't necessarily
> > apply to the other systems. My understanding that it definitely does not
> > apply to HP-UX, where major version number changes really indicate major
> > changes (unlike in Linux).

Actually, with that reasoning we would need to reintroduce the
version for Mac OS, and even go a step further and add the minor
version number as well, since since major changes have happened on Mac OS
with every single minor release for the last couple of years.

IMO, a better approach is to split the information in two parts:

 * sys.platform, which only specifies the platform name on which
   Python was built (uname -s)

 * sys.platform_build_version, which provides the full platform
   version (uname -r; either as string or as tuple or both -
   that would have to be hashed out)

It is obvious that the version number in sys.platform often 
doesn't really get used (see Victor's example). In such cases,
having access to just the build platform name is better.
In other cases, where you do need to know the version (e.g.
on Mac OS X), you can then easily get if from the new attribute,
and including the minor and even patch level release version
details (e.g. to determine whether Python was compiled with
a Windows specific service pack in place or not).
History
Date User Action Args
2011-08-22 08:57:02lemburgsetrecipients: + lemburg, loewis, vstinner, nadeem.vawda, ezio.melotti, Arfrever
2011-08-22 08:57:02lemburgsetmessageid: <1314003422.81.0.170611517188.issue12795@psf.upfronthosting.co.za>
2011-08-22 08:57:02lemburglinkissue12795 messages
2011-08-22 08:57:01lemburgcreate