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 loewis
Recipients Arfrever, amaury.forgeotdarc, eric.araujo, ezio.melotti, jwilk, lemburg, loewis, neologix, petri.lehtinen, pitrou, r.david.murray, rosslagerwall, vstinner
Date 2011-06-27.08:05:04
SpamBayes Score 9.992007e-16
Marked as misclassified No
Message-id <4E0839AF.2090106@v.loewis.de>
In-reply-to <BANLkTimA4JZa6qWb1TUan=YLgK0s9TKxdQ@mail.gmail.com>
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.

What I'm advocating is to special-case Linux (and any other system
where major version numbers don't mean much).

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

I don't argue with that. I agree the code is broken (although I disagree
that platform.system is the right answer in most cases), but that
doesn't help resolving this issue (unless the resolution is "no change",
which I still oppose to).

> Furthermore, at least on Linux, the major version number doesn't mean
> anything

Indeed - hence I propose to drop it from sys.platform if the system
is Linux.
History
Date User Action Args
2011-06-27 08:05:05loewissetrecipients: + loewis, lemburg, amaury.forgeotdarc, pitrou, vstinner, jwilk, ezio.melotti, eric.araujo, Arfrever, r.david.murray, neologix, rosslagerwall, petri.lehtinen
2011-06-27 08:05:04loewislinkissue12326 messages
2011-06-27 08:05:04loewiscreate