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 neologix
Recipients Arfrever, amaury.forgeotdarc, eric.araujo, ezio.melotti, jwilk, lemburg, loewis, neologix, petri.lehtinen, pitrou, r.david.murray, rosslagerwall, vstinner
Date 2011-06-26.21:09:14
SpamBayes Score 2.220446e-16
Marked as misclassified No
Message-id <BANLkTimA4JZa6qWb1TUan=YLgK0s9TKxdQ@mail.gmail.com>
In-reply-to <4E0791C2.3090702@v.loewis.de>
Content
> That would be incorrect for some systems. For example, FreeBSD does
> change sets of symbolic constants across system releases (mostly
> additions, but sometimes also removals). Back then, SunOS 4 and SunOS
> 5 were completely unrelated systems.
>

Well, I don't see the problem in that case.
If what's intended is to target different operating systems releases,
then sys.platform is the right choice and should be kept, since it
embeds the major version number.
The point I (and others) have been trying to make is that 99% of the
time, people using sys.platform really mean platform.system() or
uname[0], since they're only interested in the operating system, and
don't care about the release. That's true of the vast majority of such
occurrences in Lib/test, and probably true of the vast majority of the
user code base.
Furthermore, at least on Linux, the major version number doesn't mean
anything, since features are added and removed in "minor" versions,
and Linux 3.0 doesn't have anything special as far as features as
concerned (as explained by Linus, a version number is just a number).
History
Date User Action Args
2011-06-26 21:09:14neologixsetrecipients: + neologix, lemburg, loewis, amaury.forgeotdarc, pitrou, vstinner, jwilk, ezio.melotti, eric.araujo, Arfrever, r.david.murray, rosslagerwall, petri.lehtinen
2011-06-26 21:09:14neologixlinkissue12326 messages
2011-06-26 21:09:14neologixcreate