Linus recently decided that the next Linux kernel version would 3.0 [1].
As a consequence, sys.platform (which is actually MACHDEP) will be 'linux3' on machines running Linux 3 kernels, and tests checking explicitely against 'linux2' will either break and won't run.
A quick grep through the code base returns only a couple problematic places, but this should definitely be fixed.
For information, here's a - probably incomplete - list of such occurrences:

"""
./Lib/test/test_logging.py: if sys.platform in ('linux2', 'darwin'):
./Lib/test/test_sysconfig.py: sys.platform = 'linux2'
./Lib/test/regrtest.py: 'linux2':
./Lib/test/test_socket.py: if sys.platform == 'linux2':
./Lib/test/test_tarfile.py: if sys.platform == "linux2":
./Lib/distutils/tests/test_bdist_rpm.py: if sys.platform != 'linux2':
./Lib/distutils/tests/test_bdist_rpm.py: if sys.platform != 'linux2':
./Lib/distutils/tests/test_util.py: sys.platform = 'linux2'
./Lib/packaging/tests/test_config.py: inotify (0.0.1); sys.platform == 'linux2'
./Lib/packaging/tests/test_config.py: "inotify (0.0.1); sys.platform == 'linux2'"]
./setup.py: if (platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
"""

[1] http://thread.gmane.org/gmane.linux.kernel/1147415

Why should be used instead?

• sys.platform.startswith('linux')
• os.uname()[0] == 'Linux'
• platform.system() == 'Linux'
• other?

Tests like sys.platform in ('linux2', 'darwin') can be replaced by sys.platform in ('linux2', 'linux3', 'darwin'). We will have to patch this test again for Linux 4.

I would expect changing sys.platform will also break a lot of third-party code. Perhaps sys.platform can still be 'linux2' under Linux 3.x? After all, there's no significant change that deserves changing sys.platform.

sys.platform comes from Py_GetPlatform() which comes from PLATFORM define. On Linux, this define comes from Makefile: MACHDEP variable which comes from configure. Finally, MACHDEP is defined by:

ac_sys_system=`uname -s`
if test "$ac_sys_system" = "AIX" \
-o "$ac_sys_system" = "UnixWare" -o "$ac_sys_system" = "OpenUNIX"; then
	ac_sys_release=`uname -v`
else
	ac_sys_release=`uname -r`
fi
ac_md_system=`echo $ac_sys_system |
		   tr -d '/ ' | tr '[A-Z]' '[a-z]'`
ac_md_release=`echo $ac_sys_release |
		   tr -d '/ ' | sed 's/^[A-Z]\.//' | sed 's/\..*//'`
MACHDEP="$ac_md_system$ac_md_release"

I would expect changing sys.platform will also break a lot of third-
party code.

Maybe, but this would be an application bug.

Here's sys.platform current implementation:

const char *
Py_GetPlatform(void)
{
    return PLATFORM;
}

And here's the documentation, from http://docs.python.org/c-api/init.html

"""
Return the platform identifier for the current platform. On Unix, this is formed from the “official” name of the operating system, converted to lower case, followed by the major revision number"""

So it's actually documented.

Perhaps sys.platform can still be 'linux2' under Linux 3.x? After
all, there's no significant change that deserves changing
sys.platform.

Sounds like a recipe for confusion.

I suggest to change sys.platform to 'linux' in future releases (3.3). For bugfix releases (2.7, 3.2), I'd keep it as 'linux2' even on Linux 3. For security-only releases (2.6, 3.1), no change should be made.

This change is reasonable for the long term. But it *will* break a lot of code.

This change is reasonable for the long term. But it *will* break a lot of code.

[If you favor a specific change, please indicate what that is. I'm
assuming you support my proposal for the moment :-]

I agree it will break a lot of code, but it's also somewhat urgent
because we will get 'linux3' if we don't act, which will also break
a lot of code (but more subtly, since people testing their code may
do so on Linux 2, only to get bug reports that it breaks on "some"
Linux systems). I'm sure Linus Torvalds is fully aware of the possible
consequences of the version change, and just accepted the breakage
that this would cause.

It's important that we set a policy before the Linux distributions
do (which may end up choosing different policies). We don't actually
have to *release* this change quickly, since Linux distributions
who release 3.x kernels will fix their Python packages themselves.

The change to sys.platform=='linux' would break code even on current platforms.
OTOH, we have sys.platform=='win32' even on Windows 64bit; would this favor keeping 'linux2' on all versions of Linux as well?

The change to sys.platform=='linux' would break code even on current platforms.

Correct. Compared to introducing 'linux3', I consider this the better
change - it likely breaks earlier (i.e. when porting to Python 3.3).

OTOH, we have sys.platform=='win32' even on Windows 64bit; would this
favor keeping 'linux2' on all versions of Linux as well?

While this has better compatibility, it's also a constant source of
irritation. Introducing 'win64' would have been a worse choice (just
as introducing 'linux3' would: incompatibility for no gain, since
the distinction between win32 and win64, from a Python POV, is
irrelevant). Plus, Microsoft dislikes the term Win64 somewhat, and
rather wants people to refer to the "Windows API".

I personally disliked 'linux2' when it was introduced, for its
incompatibilities. Anticipating that, some day, we may have 'Linux 4',
and so on, I still claim it is better to fix this now. We could even
come up with a 2to3 fixer for people who dual-source their code.

I'm sure Linus Torvalds is fully aware of the possible
consequences of the version change, and just accepted the breakage
that this would cause.

Any application relying on sys.platform == 'linux2' is already broken.
It's exactly the same if an application checks for 'freebsd6' or
'openbsd4' : if you want to check for a specific operating system,
there's already POSIX' struct utsname sysname field, i.e. uname()[0].

Martin v. Löwis wrote:

Martin v. Löwis <martin@v.loewis.de> added the comment:

> The change to sys.platform=='linux' would break code even on current platforms.

Correct. Compared to introducing 'linux3', I consider this the better
change - it likely breaks earlier (i.e. when porting to Python 3.3).

> OTOH, we have sys.platform=='win32' even on Windows 64bit; would this
> favor keeping 'linux2' on all versions of Linux as well?

While this has better compatibility, it's also a constant source of
irritation. Introducing 'win64' would have been a worse choice (just
as introducing 'linux3' would: incompatibility for no gain, since
the distinction between win32 and win64, from a Python POV, is
irrelevant). Plus, Microsoft dislikes the term Win64 somewhat, and
rather wants people to refer to the "Windows API".

I personally disliked 'linux2' when it was introduced, for its
incompatibilities. Anticipating that, some day, we may have 'Linux 4',
and so on, I still claim it is better to fix this now. We could even
come up with a 2to3 fixer for people who dual-source their code.

I think we should consider adding a better mechanism and just
keep the old mechanism for determining sys.platform in place
(letting it break on Linux to raise awareness) and add a new better
attribute along the lines of what Martin suggested:

sys.system == 'linux', 'freebsd', 'openbsd', 'windows', etc.
(without version)

and a new

sys.system_info == system release info (named) tuple similar to
sys.version_info

to query a specific system version.

As already noted, direct sys.platform testing already breaks for
OpenBSD, FreeBSD and probably a few other OSes as well with
every major OS release, so the Linux breakage is not really new
in any way.

> The change to sys.platform=='linux' would break code even on current platforms.

Correct. Compared to introducing 'linux3', I consider this the better
change - it likely breaks earlier (i.e. when porting to Python 3.3).

FWIW, I also agree that sys.platform == 'linux' would be the better
choice. It seems there's little point having the kernel's major version
there. It's both disruptive and useless (because features are introduced
at any point, not just at new major versions).

Martin’s sys.platform = 'linux' sounds good to me too.

Just to give some statistic, in Debian we have >80 binary packages that check if sys.platform is linux2. However, it appears to me that vast majority of them is broken anyway, because what they really mean to check is:

• is this a non-Windows sytem? or
• is this a UNIX-like system? or
• is this a system with GNU userland?

IOW, they should check os.name == 'posix'?

However, it appears to me that vast majority of them is broken anyway,
because what they really mean to check is

That's exactly my point.
Code checking sys.platform against 'linux2' is already broken, there's
no point in complicating the code further, or adding a new constant.
If you want to check for a specific operating system, there's already
platform.system().

That's exactly my point.
Code checking sys.platform against 'linux2' is already broken, there's
no point in complicating the code further, or adding a new constant.
If you want to check for a specific operating system, there's already
platform.system().

I would agree with this. Perhaps the documentation for sys.platform could be changed to mention that platform.system() should maybe be used instead.

So people who say sys.platform shouldn't be used: what do you propose to do with Lib/plat-linux2 (or, more generally, Lib/plat-*)?

what do you propose to do with Lib/plat-linux2
(or, more generally, Lib/plat-*)?

What are these directories? Are they still used?

What are these directories?

Look and see for yourself.

Are they still used?

Sure. If you do "import DLFCN", it will come from that directory.

So people who say sys.platform shouldn't be used: what do you propose to
do with Lib/plat-linux2 (or, more generally, Lib/plat-*)?

These directories look useless to me.
(IIRC, putting an obvious syntax error there does not trigger any failure
in the regression suite, showing that they are never imported)

That's orthogonal to whether sys.platform should be used or not, however.
During the language summit, someone (Marc-André) brought an interesting
point: the platform does external calls to system commands such as "uname",
which can be time-consuming.

We should at least document an example of using sys.platform.startswith()
rather than exact comparison.

Regards

Antoine.

Indeed, the lib/plat- directories should continue to work just fine using linux3, correct? Or using linux, if we change sys.platform.

(Note: just because we don't import them in the test suite doesn't mean that user code in the field isn't using them...I got a few (trivial it is true, but...) hits from google code search on DLFCN.)

Changing sys.platform as Martin suggests seems like the least painful solution to me.

Note, however, that we have skips in the tests suite that do care about, for example, the FreeBSD OS major version. FreeBSD does sometimes fix the bugs we've discovered...but as someone else pointed out, this doesn't necessarily happen at a major release boundary, we just use that in the test skipping because it is the easiest thing for us to do. If sys.platform no longer included the OS major version, the test skips would probably end up being made more accurate.

the platform does external calls to system commands such as "uname",
I guess it’s the platform module.

So people who say sys.platform shouldn't be used: what do you propose
to do with Lib/plat-linux2 (or, more generally, Lib/plat-*)?

I can't speak, as I've never used those.
But can't those directories be renamed to Lib/plat-<platform.system()>?

As for the performance overhead, since the platform module caches the result of uname or other function/subprocess calls, I don't think it's a showstopper. Furthermore, I somehow doubt those functions are performance bottlenecks anyway.

Since Linux 3 is in RC now, is there a chance to reach a consensus in the near future?

I can't speak, as I've never used those. But can't those directories
be renamed to Lib/plat-<platform.system()>?

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.

Since Linux 3 is in RC now, is there a chance to reach a consensus in
the near future?

Doesn't look like it.

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

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

Le Mon, 27 Jun 2011 08:05:05 +0000,
Martin v. Löwis <report@bugs.python.org> a écrit :

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

Actually, it would itself break compatibility, because sys.platform would
jump from "linux2" to "linux" from one Python release to another. It would
therefore only be applicable, at best, to 3.3.

I think we should at least document the idiom of using
"sys.platform.startswith(...)", and mention the platform module as an
alternative. This can be done in all doc versions without breaking
anything, and in time for Linux 3 :)

New changeset 85e091c83f9a by Victor Stinner in branch 'default':
Issue bpo-12326: woops, I really mean 'linux', not 'linux2'
http://hg.python.org/cpython/rev/85e091c83f9a

New changeset b5ccdf7c032a by Victor Stinner in branch 'default':
Issue bpo-12326: refactor usage of sys.platform
http://hg.python.org/cpython/rev/b5ccdf7c032a

Where's the Doc changes? sys.platform is currently clearly documented as being "linux2" or "linux3". Adding an entry to Misc/NEWS is not enough.

New changeset bf89ff3d1ec9 by Victor Stinner in branch 'default':
Issue bpo-12326: update sys.platform doc for Linux
http://hg.python.org/cpython/rev/bf89ff3d1ec9

So what about doing the same for FreeBSD, SunOS, and Windows? The conversation about this point sort of trailed off. But, dammit, a foolish consistency is the hobgoblin of my small mind.

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

I further propose we add a "sys.platform_major_version" which would contain the OS major version number (as an integer!). That'd be 3 for Linux 3.0, 8 for FreeBSD 8, 32 for Win32, and so on. That'd let users easily reconstitute the old value of "sys.platform". (Except on Windows. But I am strangely averse to setting sys.platform to "win" on Windows.) Of course, we should determine this value at runtime rather than build time on platforms where the number could change at runtime. (A counter-example: it need not be late-binding for "windows" 32 vs 64.)

With that addition, we can now address plat-freebsd<x>.:

• Move the all existing plat-freebsd<x>/IN.py to plat-freebsd/IN<x>.py
• Write a new plat-freebsd/IN.py that uses sys.platform_version
  to read in the correct IN<x>.py.
• Alter plat-freebsd/regen to generate IN<x>.py
  I suspect plat-freebsd<x> should have used the run-time OS major version all along, so this would be an improvement! And since FreeBSD is the only OS with more than one plat-* entry, the plat-* problem is solved.

I'm happy to open a new issue discussing this if that's the right thing to do.

Larry: the scope of this bug was narrowed to the linux breakage only; see bpo-12795 for other platforms.

In case of plat-* directories, please see issue bpo-12619, which proposes some changes.

So what about doing the same for FreeBSD, SunOS, and Windows?

I agree that's definitely out of scope of this issue.

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

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

Where's the doc updates for the stable branches?

Also, we might think about removing this version number everywhere.

Where's the doc updates for the stable branches?

I don't know how to update this documentation. Can someone update the
doc, or suggest a patch?

Also, we might think about removing this version number everywhere.

Please, see my issue http://bugs.python.org/issue12795 for this topic.

Georg Brandl wrote:

Also, we might think about removing this version number everywhere.

+1

Martin v. Löwis wrote:

Martin v. Löwis <martin@v.loewis.de> added the comment:

> So what about doing the same for FreeBSD, SunOS, and Windows?

I agree that's definitely out of scope of this issue.

We could change the title of the ticket :-)

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

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)

We could change the title of the ticket :-)

No please, move the discussion to bpo-12795 which has a well defined title. This issue is closed. (bpo-12795 has also a patch) Well, bpo-12795 is also close but you can reopen it if you explain why :-)

STINNER Victor wrote:

STINNER Victor <victor.stinner@haypocalc.com> added the comment:

> We could change the title of the ticket :-)

No please, move the discussion to bpo-12795 which has a well defined title. This issue is closed. (bpo-12795 has also a patch) Well, bpo-12795 is also close but you can reopen it if you explain why :-)

Ok, I moved the discussion there.

> I agree that's definitely out of scope of this issue.

We could change the title of the ticket :-)

Please keep the issue closed... The issue at hand was that Linux 3
is released, and broke several applications. This issue has been
resolved.

For the other platforms, I don't see any issue to be fixed (except
for achieving "foolish consistency"). If something is *actually*
broken, it needs to be fixed.

I don't know how to update this documentation. Can someone update the
doc, or suggest a patch?

This is a strange statement. You changed the implementation, so you should be able to change the documentation accordingly.

Something like:

diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
--- a/Doc/library/sys.rst
+++ b/Doc/library/sys.rst
@@ -699,20 +699,21 @@ always available.
    This string contains a platform identifier that can be used to append
    platform-specific components to :data:`sys.path`, for instance.
 
-   For Unix systems, this is the lowercased OS name as returned by ``uname -s``
-   with the first part of the version as returned by ``uname -r`` appended,
-   e.g. ``'sunos5'`` or ``'linux2'``, *at the time when Python was built*.
-   Unless you want to test for a specific system version, it is therefore
-   recommended to use the following idiom::
+   For Unix systems, except on Linux, this is the lowercased OS name as
+   returned by ``uname -s`` with the first part of the version as returned by
+   ``uname -r`` appended, e.g. ``'sunos5'`` or ``'linux2'``, *at the time when
+   Python was built*.  Unless you want to test for a specific system version,
+   it is therefore recommended to use the following idiom::
 
-      if sys.platform.startswith('linux'):
-          # Linux-specific code here...
+      if sys.platform.startswith('freebsd'):
+          # Freebsd-specific code here...
 
    For other systems, the values are:
 
    ================ 

===========================
System :data:platform value
================ ===========================

• Linux 'linux2'
  Windows 'win32'
  Windows/Cygwin 'cygwin'
  Mac OS X 'darwin'

?

I don't think that I need a :versionchanged:`2.7.3`.

I think the doc patch should mention that:

1. it's 'linux2' also on Linux 3;
2. why it's not 'linux3';
   The why can be done in a footnote and explain that Linux 3 doesn't introduce new major features and that changing the string to 'linux3' would have just broken needlessly code that was checking for sys.platform == 'linux2'.
   It should probably also mention that in future versions (i.e. 3.3+) this string has been changed to be just 'linux' and that keep checking for sys.platform == 'linux2' is therefore discouraged even after this change.

I've updated 3.2 docs in e11b4c945f7e (currently in the release clone, will be merged to upstream after the release of 3.2.2.)

Please commit a similar change to the 2.7 branch.

Please delete Lib/plat-linux3 directories on 2.7 and 3.2 branches.

New changeset 265da863d017 by Victor Stinner in branch '3.2':
Issue bpo-12326: sys.platform is now always 'linux2' on Linux
http://hg.python.org/cpython/rev/265da863d017

New changeset e11b4c945f7e by Georg Brandl in branch '3.2':
Update sys.platform doc for bpo-12326.
http://hg.python.org/cpython/rev/e11b4c945f7e

New changeset d95c4b030eac by Victor Stinner in branch '2.7':
Issue bpo-12326: Remove plat-linux3 directory
http://hg.python.org/cpython/rev/d95c4b030eac

New changeset cb47cf5138a4 by Victor Stinner in branch '3.2':
Issue bpo-12326: Remove plat-linux3 directory
http://hg.python.org/cpython/rev/cb47cf5138a4

New changeset 0fe571d43317 by Victor Stinner in branch '2.7':
Update sys.platform doc for bpo-12326.
http://hg.python.org/cpython/rev/0fe571d43317

I removed Lib/plat-linux3 from Python 2.7 and 3.2, and updated doc of Python 2.7. I close this issue (again).

I have a better idea... Why don't we change the "linux2" string into just "linux". That way we will never run into this kind of issue, even in the future when Linux kernel version 4 is going to exist. Any thoughts on this?

On Oct 04, 2011, at 01:03 PM, Boštjan Mejak wrote:

I have a better idea... Why don't we change the "linux2" string into just
"linux". That way we will never run into this kind of issue, even in the
future when Linux kernel version 4 is going to exist. Any thoughts on this?

Python 3.3 already sets sys.platform to 'linux'. It can't be done for older
versions due to backward compatibility.