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

@neologix: I don't understand why do you want to hurry, this issue will not be fixed in the next release (3.2.1, it's too late), and I don't think that the next release (3.3? or is it something before?) will come before few months.

--

I don't think that replacing "linux3" by "linux" for sys.platform does change anything. I agree with neologix:

> Any application relying on sys.platform == 'linux2' is already broken.

Even if we change sys.platform in Python 2.7.3, 3.2.2 and/or 3.3, I bet that some Linux distro will bundle older versions with Linux 3. It means that we will have "linux2", "linux3", "linux". It is just worse.

--

I propose to just patch the code checking for linux2 where it is inappropriate. I attached linux3.patch: patch for Python 3.2 fixing mention of linux2. It replaces sys.platform == 'linux2' by sys.platform in ('linux2', 'linux3'), os.uname()[0] == 'Linux' or platform.system() == 'Linux', depending on the context. In setup.py, I used os.uname()[0] to avoid bootstrap issues, but it is maybe possible to use platform.system() there.

--

@loewis: What is the code responsable to use/load Lib/plat-* modules?

Can we use a symlink from plat-linux2 to plat-linux3? Or should we copy the whole directory?

--

@lemburg: What will be the value of sys.system on Cygwin? "windows" or "cygwin"? It looks like sys.platform is "cygwin" if Python was compiled using Cygwin, "win32" if Python was compiled using Visual Studio. sys.system is maybe redundant with platform.system() (except that platform requires to call os.uname, but only once).

@lemburg: sys.system_info looks to be redundant with the platform module.

> @neologix: I don't understand why do you want to hurry, this issue will not be fixed in the next release (3.2.1, it's too late), and I don't think that the next release (3.3? or is it something before?) will come before few months.
>

Well, I'm not familiar (yet :-) with the release cycle, but I was
concerned with the upcoming Linux 3.0 release (probably a matter of
weeks now).

But if we can't reach a consensus here, we should maybe move this
discussion to the mailing list.

while this is sorted out, I propose to apply the following workaround not to introduce `linux3', at least for the branches:

--- a/configure.in      2011-06-11 17:46:28.000000000 +0200
+++ b/configure.in      2011-06-19 22:32:05.852934453 +0200
@@ -293,6 +293,7 @@
        MACHDEP="$ac_md_system$ac_md_release"
 
        case $MACHDEP in
+       linux3) MACHDEP="linux2";;
        cygwin*) MACHDEP="cygwin";;
        darwin*) MACHDEP="darwin";;
        atheos*) MACHDEP="atheos";;

> while this is sorted out, I propose to apply the following workaround
> not to introduce `linux3', at least for the branches:

It's too late, since existing versions won't have the patch and will
show "linux3" when the kernel gets upgraded.

I think we'd better bite the bullet and accept the "linux3" value.

about the plat-*/ files:

they are even wrong for some linux architectures, because some constants like the DLFCN constants have different values depending on the platform/architecture (can't find the issue proposing architecture dependent plat-linux2-<arch> directories).

New changeset 53d2d30d6ca0 by Antoine Pitrou in branch '2.7':
Issue #12326: document the recommended idiom for checking sys.platform on Unix systems.
http://hg.python.org/cpython/rev/53d2d30d6ca0

New changeset 8bc9dbc61ba6 by Antoine Pitrou in branch '3.2':
Issue #12326: document the recommended idiom for checking sys.platform on Unix systems.
http://hg.python.org/cpython/rev/8bc9dbc61ba6

New changeset 19b3b2d93a63 by Antoine Pitrou in branch 'default':
Issue #12326: document the recommended idiom for checking sys.platform on Unix systems.
http://hg.python.org/cpython/rev/19b3b2d93a63

Here we go, first Linux3-related bug report:
https://bugs.gentoo.org/show_bug.cgi?id=374579 (see issue #12571).

> Here we go, first Linux3-related bug report:
> https://bugs.gentoo.org/show_bug.cgi?id=374579 (see issue #12571).

Oh, some people use the DLFCN module :-)

--

I'm still in favor of keeping sys.platform == 'linux3', and you?

For plat-linux3, should we regenerate this directory (I cannot do that, I don't have Linux 3.0 yet) or can we just use a symbolic link? I read that Linux 3.0 doesn't break the API, so I suppose that constants are the same. Or can we try by copying plat-linux2 to plat-linux3?

> I'm still in favor of keeping sys.platform == 'linux3', and you?
>

So do I.

> For plat-linux3, should we regenerate this directory (I cannot do that, I
> don't have Linux 3.0 yet) or can we just use a symbolic link? I read that
> Linux 3.0 doesn't break the API, so I suppose that constants are the same.
> Or can we try by copying plat-linux2 to plat-linux3?
>

I've just had a quick look, but it seems that plat-<sys.platform>
contains header definitions, so it's more function of the libc than
the kernel version. It probably makes sense on operating systems which
have a real notion of release (i.e. a consistent kernel/user-space,
like AIX or *BSD), but not so much on Linux. Copying plat-linux2 to
plat-linux3 should be just fine.

Your patch looks fine to me, except for this:
-        if (platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
-                        'freebsd7', 'freebsd8')
-            or platform.startswith("gnukfreebsd")):
+        if os.uname()[0] in ('Linux', 'FreeBSD'):

Why not use platform.system(), to be consistent?

> Copying plat-linux2 to plat-linux3 should be just fine.

Done in issue12571.

> Your patch looks fine to me, except for this:
> -        if (platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
> -                        'freebsd7', 'freebsd8')
> -            or platform.startswith("gnukfreebsd")):
> +        if os.uname()[0] in ('Linux', 'FreeBSD'):
> 
> Why not use platform.system(), to be consistent?

I'm not sure that thp platform module can be used in setup.py 
(bootstrap issue?). It should be tested.

Le mardi 19 juillet 2011 à 23:20 +0000, STINNER Victor a écrit :
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> > Your patch looks fine to me, except for this:
> > -        if (platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
> > -                        'freebsd7', 'freebsd8')
> > -            or platform.startswith("gnukfreebsd")):
> > +        if os.uname()[0] in ('Linux', 'FreeBSD'):
> > 
> > Why not use platform.system(), to be consistent?
> 
> I'm not sure that thp platform module can be used in setup.py 
> (bootstrap issue?). It should be tested.

Why don't you just use platform.startswith? It would avoid introducing
bugs due to subtle differences between uname, platform or
platform.system.

It seems currently that in python 3.2 sys.platform is linux2 even though it is running linux 3

> It seems currently that in python 3.2 sys.platform is linux2
> even though it is running linux 3

It's maybe because you ran ./configure with Linux 2.x.y (see msg138254). Try make distclean && ./configure --with-debug && make.

> I'm still in favor of keeping sys.platform == 'linux3', and you?

Still -1. It should be renamed to 'linux' in future releases, and
back-patched to 'linux2' for maintenance releases.

As for releases that are already out - users should be informed to
not use those on Linux 3 (or not use Linux 3 on systems where they
have the old Python releases).

> Still -1. It should be renamed to 'linux' in future releases, and
> back-patched to 'linux2' for maintenance releases.
>

I really don't see any advantage to this solution:
- sys.platform currently has a clear and documented value (OS name +
major release), this change would break that
- sys.platform is actually really simple, it returns MACHDEP: this
change would require complicating the code
- code testing sys.platform for equality is already broken: there's
the exact same problem with FreeBSD, OpenBSD and any other operating
system I can think of: 99% of the time, people checking sys.platform
really mean sys.platform.startswith(<OS name>), os.uname()[0] or
platform.system(), i.e. the OS name, and don't care about the release
- this change would introduce an inconsistency between Python
releases, which would make the problem worse
- this information is already provided by os.uname() and platform.system()
- finally, this would not solve the problem at hand

> As for releases that are already out - users should be informed to
> not use those on Linux 3 (or not use Linux 3 on systems where they
> have the old Python releases).
>

Advise users to not use Python on Linux 3 - which doesn't break break
backward compatibility in any way - sounds like a really bad idea, and
would give Python a bad press for no reason.
I mean, it's just a version number, and a really minor bug:
Chromium and matplotlib already fixed this in their code using
sys.platform.startswith('linux') [1] [2].
It's that simple, I don't see what there's so much to talk about here.

[1] http://codereview.chromium.org/7172016
[2] https://github.com/matplotlib/matplotlib/commit/aaef94485cf71ed3181e0adc5577d1a8911f6544

I give up. Call it 'linux3', then.

this does sound very ugly.

so we get now another mostly unmaintained platform directory? unfortunately the generated header files are almost never updated during a releaes cycle.

and we repeat the mistakes that some constants differ on some architectures?

It's too late to "fix" sys.platform.

See issue #12619 for potential solution for platform-specific modules.

> this does sound very ugly.
> 
> so we get now another mostly unmaintained platform directory?
> unfortunately the generated header files are almost never updated
> during a releaes cycle.

I would be +1 to deprecate this stuff, but that's quite separate from
the issue of not breaking on Linux 3.x.

FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3.

On Mon, Jul 25, 2011 at 13:50, Éric Araujo <report@bugs.python.org> wrote:
> Éric Araujo <merwok@netwok.org> added the comment:
>
> FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3.

Luckily that has just been reverted.

Oh wow, so it depends on the *build* time major version? That's really not useful at all for linux 2.x and 3.x; there is nothing useful anyone can possibly do with the distinction between platform == "linux2" and platform == "linux3". All it could possibly do is to break apps.

Given that:
a) old versions of Python won't even build without a patch and
b) changing platform to linux3 will break a lot of python apps that check sys.platform. 
c) It's completely useless to change it, as the change contains no actual information.

Why is forcing sys.platform to remain linux2 not the *obviously right thing to do*?

@Sandro:

>> FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3.

>Luckily that has just been reverted.

No, I don't think it has: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633015

On Debian Wheezy and Ubuntu 11.10:

$ python2.7 -c 'import sys; print sys.platform'
linux2
$ python3.2 -c 'import sys; print(sys.platform)'
linux2

oneiric$ uname -a
Linux resist 3.0.0-8-generic #11-Ubuntu SMP Fri Aug 12 20:23:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
wheezy$ uname -a
Linux chemistry 3.0.0-1-amd64 #1 SMP Sun Jul 24 02:24:44 UTC 2011 x86_64 GNU/Linux

I agree with MvL that Python 3.3 should set sys.platform to 'linux' and all stable releases should be patched to return 'linux2' on MACHDEP='linux3' systems.  configure.in already special cases cygwin* and darwin* to the major-version-number-less platform string, so this doesn't seem like much of a stretch to me for linux.  Since applications/libraries that already test against literal sys.platform values will be broken no matter what we do (except perhaps retain 'linux2' for perpetuity, which doesn't seem like a good idea), I think we should make a clean break from the major version number in Python 3.3 and keep backward compatibility for released Pythons.  Seems like the least worst option to me.

On Tue, Aug 16, 2011 at 16:21, Barry A. Warsaw <report@bugs.python.org> wrote:
>
> Barry A. Warsaw <barry@python.org> added the comment:
>
> @Sandro:
>
>>> FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3.
>
>>Luckily that has just been reverted.
>
> No, I don't think it has: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633015
>
> On Debian Wheezy and Ubuntu 11.10:
>
> $ python2.7 -c 'import sys; print sys.platform'
> linux2
> $ python3.2 -c 'import sys; print(sys.platform)'
> linux2

that's because you're on wheezy, that has 2.7.2-3, while the version
which has the change reverted is -4 (still not transition to testing,
since outdated on kbsd-i386)

On Aug 16, 2011, at 02:28 PM, Sandro Tosi wrote:

>that's because you're on wheezy, that has 2.7.2-3, while the version
>which has the change reverted is -4 (still not transition to testing,
>since outdated on kbsd-i386)

I think it's back in -5 though.

$ apt-cache show python2.7 | grep Version
Version: 2.7.2-5

(On Ubuntu)

Another datapoint:

For Fedora 16, I haven't done any downstream patching (so far), because we hadn't run into any downstream problems.

I did some digging into why we're _not_ experiencing issues.

Currently for Fedora 16, we're shipping kernel-3.0 with python-2.7.2-4.fc16.x86_64 and python is reporting:

  $ python -c"import sys; print(sys.platform)"
  linux2

I investigated why we have this discrepancy:  "uname" with the build environment for that RPM happens to be reporting a kernel-2*, whereas we're shipping a kernel-3*:

  http://koji.fedoraproject.org/koji/taskinfo?taskID=3187563

What's happening here is that although the chroot that the build was done in [1] has:
  kernel-3.0-0.rc6.git0.1.fc16.x86_64.rpm

running "uname" in the chroot environment is reporting the kernel that's actually running, outside the chroot, which was:
  2.6.32
and thus we have:
  checking MACHDEP... linux2
within the build log [2]

So in this case, "sys.platform"'s final digit is reporting the major release of the kernel running outside the chroot-ed build environment (ironically bearing even less relationship to that of the currently-running kernel :( )

Hope this is helpful

[1] http://koji.fedoraproject.org/koji/rpmlist?buildrootID=1096117%20&start=50&order=nvr&type=component
[2] http://kojipkgs.fedoraproject.org/packages/python/2.7.2/4.fc16/data/logs/x86_64/build.log

My patch version 2: don't test for a specific major version of an OS, test only its name. My patch now changes also tests for FreeBSD, NetBSD, OpenBSD, (...), and the _expectations list in regrtest.py.

2011/8/16 Dave Malcolm <report@bugs.python.org>:
> So in this case, "sys.platform"'s final digit is reporting the major release of the kernel running outside the chroot-ed build environment (ironically bearing even less relationship to that of the currently-running kernel :( )
>
> Hope this is helpful

Thanks Dave.
To me, this sounds like yet another reason not to use sys.platform (C) (TM) (R).

> My patch version 2

Looks good to me.

New changeset 50f1922bc1d5 by Victor Stinner in branch 'default':
Issue #12326: don't test the major version of sys.platform
http://hg.python.org/cpython/rev/50f1922bc1d5

> New changeset 50f1922bc1d5 by Victor Stinner in branch 'default':

I will backport the fix to 2.7 and 3.2.

> I will backport the fix to 2.7 and 3.2.

Uh, wait, so does that mean you're *not* going to do the compatibility-preserving thing and force sys.platform to stay linux2 even when python is built (BUILT! not run!) on a machine where the active kernel is linux 3.x?

On Aug 18, 2011, at 01:20 AM, James Y Knight wrote:

>James Y Knight <foom@users.sourceforge.net> added the comment:
>
>> I will backport the fix to 2.7 and 3.2.
>
>Uh, wait, so does that mean you're *not* going to do the
>compatibility-preserving thing and force sys.platform to stay linux2 even
>when python is built (BUILT! not run!) on a machine where the active kernel
>is linux 3.x?

My question too!  I would say that stable releases should probably not get
this change, but should force sys.platform to linux2 on 3.x kernels.

BTW, does anybody think sys.platform should use a more dynamic approach for
calculating its value?  Well, maybe not necessary if Python 3.3 will just say
'linux'.

> My question too!  I would say that stable releases should probably not get
> this change, but should force sys.platform to linux2 on 3.x kernels.
>

The point is precisely that we don't change anything: applications
checking against sys.platform are already broken, there's no reason to
comfort them into using this defective check.
The applications that encountered the problem (chromium, matplotlib
and probably others) already performed the change to
sys.platform.startswith(), so it's really the only way to go.

> BTW, does anybody think sys.platform should use a more dynamic approach for
> calculating its value?  Well, maybe not necessary if Python 3.3 will just say
> 'linux'.

There's already platform.system() for that.

On Aug 18, 2011, at 01:15 PM, Charles-François Natali wrote:

>Charles-François Natali <neologix@free.fr> added the comment:
>
>> My question too!  I would say that stable releases should probably not get
>> this change, but should force sys.platform to linux2 on 3.x kernels.
>
>The point is precisely that we don't change anything: applications
>checking against sys.platform are already broken, there's no reason to
>comfort them into using this defective check.
>The applications that encountered the problem (chromium, matplotlib
>and probably others) already performed the change to
>sys.platform.startswith(), so it's really the only way to go.

I still think that sys.platform for the stable releases should never report
'linux3'.  Updating the various conditionals *probably* has low risk of
regression, but I think you have to check that very carefully.

>> BTW, does anybody think sys.platform should use a more dynamic approach for
>> calculating its value?  Well, maybe not necessary if Python 3.3 will just
>> say 'linux'.
>
>There's already platform.system() for that.

TOOWTDI

> I still think that sys.platform for the stable releases should 
> never report 'linux3'

I don't understand why do you want to have a special case for Linux. sys.platform is already different for each major version of:

 * FreeBSD
 * OpenBSD
 * NetBSD
 * unixware
 * openunix
 * sco_sv
 * sunos
 * hp-ux

(Ok, some of them are dead and you cannot expect new major versions :-))

On Aug 18, 2011, at 03:45 PM, STINNER Victor wrote:

>I don't understand why do you want to have a special case for
>Linux. sys.platform is already different for each major version of:

We already have special cases for cygwin, darwin, and irix (okay, the latter
is dead too :).  I'm just suggesting one more special case for linux*

(see configure.in and search for MACHDEP)

> I'm just suggesting one more special case for linux*

You suggest to have a special case in Python 2.7 and 3.2, but not in Python 3.3 (3.1, 2.6, etc.)?

On Aug 18, 2011, at 03:58 PM, STINNER Victor wrote:

>
>STINNER Victor <victor.stinner@haypocalc.com> added the comment:
>
>> I'm just suggesting one more special case for linux*
>
>You suggest to have a special case in Python 2.7 and 3.2, but not in Python
>3.3 (3.1, 2.6, etc.)?

Correct.  We can't touch Python 3.1, 2.6, or earlier because those are all in
security-only mode, and unless a specific security related issue is
identified, the change should not be made there.  That's just life (a recent
similar example is support for multiarch in newer Debian and Ubuntu releases -
we just don't support that in security-only Pythons).

We can and should change Python 3.2 and 2.7 to only report 'linux2' for
backward compatibility.

For Python 3.3, we should do the right thing, which IMO is to set sys.platform
to 'linux' without the version number.  In parallel we can change the stdlib
tests to use .startswith() and encourage third party developers to use
.startswith() also.

> Correct.  We can't touch Python 3.1, 2.6, or earlier because those are all in
> security-only mode, and unless a specific security related issue is
> identified, the change should not be made there.  That's just life (a recent
> similar example is support for multiarch in newer Debian and Ubuntu releases -
> we just don't support that in security-only Pythons).
> 
> We can and should change Python 3.2 and 2.7 to only report 'linux2' for
> backward compatibility.

It means someone upgrading from 2.6 to 2.7 will see sys.platform change
from "linux3" to "linux2". That breaks compatibility.

> For Python 3.3, we should do the right thing, which IMO is to set sys.platform
> to 'linux' without the version number.  In parallel we can change the stdlib
> tests to use .startswith() and encourage third party developers to use
> .startswith() also.

The latter is already done in the documentation.

> For Python 3.3, (...) In parallel we can change the stdlib
> tests to use .startswith()

done, see my changeset 50f1922bc1d5

If we change Python 2.7.3 and 3.2.2 to force sys.platform to linux2 (instead of linux3) and use "linux" in Python 3.3, we will have 3 differents values of sys.platform if Python is built on Linux 3:

 - "linux3" on Python <= 2.7.2 or Python <= 3.2.1
 - "linux2" on 2.7.3 <= Python or 3.2.2 <= Python < 3.3
 - "linux" on Python >= 3.3

I don't see how it will help backward or forward compatibility... It's exactly as the current state (sys.platform == 'linux3' on all Python versions): applications have to use sys.platform.startswith() to work correctly on any Linux version.

Well, except maybe if you plan to write applications working only on Python >= 2.7.3? ... this version is not released yet.

> The point is precisely that we don't change anything: applications
> checking against sys.platform are already broken, there's no reason to
> comfort them into using this defective check.

You grossly misunderstand the concept of "backwards compatibility".
At times, features get added to allow even buggy (or perceived-buggy)
applications to continue to work under a change.

> The applications that encountered the problem (chromium, matplotlib
> and probably others) already performed the change to
> sys.platform.startswith(), so it's really the only way to go.

I'm very certain that not all applications have been changed yet.

> I don't understand why do you want to have a special case for Linux. 
> sys.platform is already different for each major version of:

That's because Linux uses major version numbers in an entirely different
way than these systems. There is a traditional usage of major versions
(to indicate significant changes), and the systems you list follow this
practice. And then there are systems that break with that tradition, and
use the major version for marketing and other purposes, and Linux is one
of them.

> Well, except maybe if you plan to write applications working only on Python >= 2.7.3? ... this version is not released yet.

No, of course I don't plan on writing new code that checks sys.platform == 'linux2'. That's ridiculous.

I plan to use *already written* applications on Python<2.7.3 binaries that have already been built (and thus were built on a 2.x kernel and report linux2), on Python>=2.7.3 which will be fixed to continue reporting linux2, and on Python<2.7.3 which have had the same fix backported to them by distros, since Python upstream won't do it for earlier branches.

> It means someone upgrading from 2.6 to 2.7 will see sys.platform change
> from "linux3" to "linux2". That breaks compatibility.

No, it doesn't. Code that works on 2.6 and Linux 3 will likely support
both linux2 and linux3, so it will continue just fine on 2.7.

I'd rather phrase this differently: Python 2.6 does not support Linux 3.
Tough luck, since Linux 3 was released long after Python 2.6.

> - "linux3" on Python <= 2.7.2 or Python <= 3.2.1
> - "linux2" on 2.7.3 <= Python or 3.2.2 <= Python < 3.3
> - "linux" on Python >= 3.3
> 
> I don't see how it will help backward or forward compatibility...

It's very easy to see. In the long term (ten years) Python 2 will
be gone, and so will be Linux 2. Linux 4 may be released.

If we continue with the current approach, we will have the same
problems again (as we already did when Linux 2 was released). If
we change to just "linux" now, it will have no effect when Linux 4
is released.

As for the cases where "linux3" is reported: I don't care that
they break. Python 2.6 and Python 2.7.2 is incompatible with
Linux 3. Users should be advised to a) not upgrade to Linux 3, or
b) simultaneously upgrade to a newer Python release, or
c) work-around in their applications.

I expect that most users chose a) for some time to come (until
the Linux distributions ship the new kernels), and that the Linux
distributions chose b) and c).

> Well, except maybe if you plan to write applications working only on
> Python >= 2.7.3? ... this version is not released yet.

With Python 2.7.3, people don't have the change their applications at
all. They just have to wait for the Linux upgrade until Python 2.7.3
is released.

> > It means someone upgrading from 2.6 to 2.7 will see sys.platform change
> > from "linux3" to "linux2". That breaks compatibility.
> 
> No, it doesn't. Code that works on 2.6 and Linux 3 will likely support
> both linux2 and linux3, so it will continue just fine on 2.7.

Then, let's just advise that all code follow the same path and use
sys.platform.startswith() (which is really not a difficult change to
make).

> Then, let's just advise that all code follow the same path and use
> sys.platform.startswith() (which is really not a difficult change to
> make).

Antoine, please accept that people want better backwards compatibility
than just recommendations how to rewrite applications. They want the
code to continue to work *unmodified*.

The proposed mechanism achieves this for the bug fix releases.

> > Then, let's just advise that all code follow the same path and use
> > sys.platform.startswith() (which is really not a difficult change to
> > make).
> 
> Antoine, please accept that people want better backwards compatibility
> than just recommendations how to rewrite applications.

You just said that "we" already had the same problem when Linux 2 was
released. So hopefully "people want better backwards compatibility"
would have learnt from that experience, and stopped hard-coding version
numbers.

Really, it's not difficult to understand that code testing for "linux2"
will stop working when "linux3" gets released. It's an obvious bug which
is also obvious to fix. Whether or not the Linux version numbering
scheme makes sense is a totally separate concern (which I agree may be
addressed by returning "linux" in 3.3).

> You just said that "we" already had the same problem when Linux 2 was
> released. So hopefully "people want better backwards compatibility"
> would have learnt from that experience, and stopped hard-coding version
> numbers.

No, when Linux 2 was released (1996), Python didn't have the relevance
it has today. Most of the code referring to linux2 was probably written
after that date, and with the assumption that it may well be the final
major version Linux will ever get.

> Really, it's not difficult to understand that code testing for "linux2"
> will stop working when "linux3" gets released.

This doesn't matter. People will still complain. And, as there is an
obvious work-around, why not make people's lives easier?

> > Really, it's not difficult to understand that code testing for "linux2"
> > will stop working when "linux3" gets released.
> 
> This doesn't matter. People will still complain. And, as there is an
> obvious work-around, why not make people's lives easier?

At the cost of some additional confusion, though.

>>> Really, it's not difficult to understand that code testing for "linux2"
>>> will stop working when "linux3" gets released.
>>
>> This doesn't matter. People will still complain. And, as there is an
>> obvious work-around, why not make people's lives easier?
> 
> At the cost of some additional confusion, though.

As you can see, the compile-time nature of the current implementation
causes similar confusion (even to experienced users). With the proposed
solution, most people won't even notice that there is an issue, so they
won't be confused. When they migrate to 3.3, they notice the change, and
accept it as a new feature - and they notice the change regardless of
whether they run a 2.x or 3.x kernel.

With the alternative approach (linux3), people may continue to release
buggy applications for years and not even notice during testing as they
use a Python binary compiled on linux2.

Some thoughts:

 * We can't change the value of a system variable in a patch level
   release. It's not a bug and the change is not motivated by
   Python, but by the OS vendor. So changes to released versions
   are not possible. They are also not necessary - see the next bullet.

 * Porting to a new OS version is always an application level problem,
   not a programming language one; you cannot expect applications
   written for Linux 2.x to run without problems on 3.x - much like you
   cannot expect Python 2.x applications to run without problems
   on Python 3.x.

 * Removing the version number from the platform string should only
   be done in case a new variable gets introduced that provides the
   full version. Using the platform module would be possible, but
   can be expensive, so having this value as standard sys module
   variable is a better approach.

   Otherwise, removing the version is a good thing to do for
   Python 3.3 onwards.

 * The same change should be applied to *all* other platform strings,
   not only Linux, but the *BSDs and the others as well.

 * Application writers need to be made aware of the change, since
   sys.platform is not only used in Python programs, but also
   to build e.g. path names, file names, log ids, etc. etc.

M.A., your comments do not make sense in the context of Linux. It does not actually require porting -- Linux 2.6.39 to Linux 3.0 is no more disruptive than Linux 2.6.38 to Linux 2.6.39. *Except* that python ill-advisedly exported a "platform" string which included a value which is completely irrelevant on Linux, and has now changed.

The bug here that should be fixed in release branches is that Python put the build-time linux major kernel version in sys.platform in the first place, instead of making it just be "linux". If anyone had a time machine, the right thing would be to go back in time and make Python never put the "2" there. But, since they're hard to come by (rumors to the contrary aside...), the best fix at this point is to retain consistency with earlier patch releases and force it to remain "linux2" no matter what.

Again, the number provides literally *no* useful information. You can compile Python on kernel version 2.x and then run it on a 3.x kernel (sys.platform will be "linux2" in that case). You can also compile python on a 3.x kernel and then run it on a 2.x kernel (sys.platform will be "linux3" in that case). Other than the 2 vs 3 encoded into a bunch of places inside Python, the two copies of python should be 100% identical.

So, there is also no need to provide this useless value under a different variable name.

BTW, all the above goes for everywhere Python uses "linux[23]" right now, such as pathnames, not just literally the value of sys.platform.

On Aug 18, 2011, at 05:54 PM, Martin v. Löwis wrote:

>As for the cases where "linux3" is reported: I don't care that
>they break. Python 2.6 and Python 2.7.2 is incompatible with
>Linux 3. Users should be advised to a) not upgrade to Linux 3, or
>b) simultaneously upgrade to a newer Python release, or
>c) work-around in their applications.
>
>I expect that most users chose a) for some time to come (until
>the Linux distributions ship the new kernels), and that the Linux
>distributions chose b) and c).

In fact, for Debian and Ubuntu, we had several breakages due to sys.platform
== 'linux3' so for all Pythons we still support, we're going to force it back
to 'linux2'.  This fixed all those broken packages without any of them needing
to be changed.

James Y Knight wrote:
> 
> James Y Knight <foom@users.sourceforge.net> added the comment:
> 
> M.A., your comments do not make sense in the context of Linux. It does not actually require porting -- Linux 2.6.39 to Linux 3.0 is no more disruptive than Linux 2.6.38 to Linux 2.6.39. *Except* that python ill-advisedly exported a "platform" string which included a value which is completely irrelevant on Linux, and has now changed.

That's a details of how Linux is managed. In terms of releases,
it's a new major release.

> The bug here that should be fixed in release branches is that Python put the build-time linux major kernel version in sys.platform in the first place, instead of making it just be "linux". If anyone had a time machine, the right thing would be to go back in time and make Python never put the "2" there. But, since they're hard to come by (rumors to the contrary aside...), the best fix at this point is to retain consistency with earlier patch releases and force it to remain "linux2" no matter what.
> 
> Again, the number provides literally *no* useful information. You can compile Python on kernel version 2.x and then run it on a 3.x kernel (sys.platform will be "linux2" in that case). You can also compile python on a 3.x kernel and then run it on a 2.x kernel (sys.platform will be "linux3" in that case). Other than the 2 vs 3 encoded into a bunch of places inside Python, the two copies of python should be 100% identical.
> 
> So, there is also no need to provide this useless value under a different variable name.
>
> BTW, all the above goes for everywhere Python uses "linux[23]" right now, such as pathnames, not just literally the value of sys.platform.

Sure, you can compile and run Python on both versions of Linux, but what
if your application uses features that are only present in Linux 3.0
and later ?

BTW: The new attribute should contain the complete version number,
not just the major version. `uname -r` would provide a good start.

Barry A. Warsaw wrote:
> 
> Barry A. Warsaw <barry@python.org> added the comment:
> 
> On Aug 18, 2011, at 05:54 PM, Martin v. Löwis wrote:
> 
>> As for the cases where "linux3" is reported: I don't care that
>> they break. Python 2.6 and Python 2.7.2 is incompatible with
>> Linux 3. Users should be advised to a) not upgrade to Linux 3, or
>> b) simultaneously upgrade to a newer Python release, or
>> c) work-around in their applications.
>>
>> I expect that most users chose a) for some time to come (until
>> the Linux distributions ship the new kernels), and that the Linux
>> distributions chose b) and c).
> 
> In fact, for Debian and Ubuntu, we had several breakages due to sys.platform
> == 'linux3' so for all Pythons we still support, we're going to force it back
> to 'linux2'.  This fixed all those broken packages without any of them needing
> to be changed.

Ah, those lazy Debian/Ubuntu folks again ;-)

> Sure, you can compile and run Python on both versions of Linux, but
> what if your application uses features that are only present in Linux
> 3.0 and later ?

This comment is making me think you've missed just how irrelevant kernel version 3.0 really is. To a first approximation, it *has no new features*. Now, to be sure, there are a couple of things, sure. Just like there were a couple new features in 2.6.39 two months earlier, 2.6.38 two months before that, 2.6.37 two months before that, and so on, every 2-3 months, back to the release of 2.6.7 or so in 2004.

> BTW: The new attribute should contain the complete version number,
> not just the major version. `uname -r` would provide a good start.

To be useful, that would have to be a runtime-computed thing, not the build-time value that sys.platform's trailing number is. But we already have that: os.uname(). It certainly doesn't need a second name.

James Y Knight wrote:
> 
> James Y Knight <foom@users.sourceforge.net> added the comment:
> 
>> Sure, you can compile and run Python on both versions of Linux, but
>> what if your application uses features that are only present in Linux
>> 3.0 and later ?
> 
> This comment is making me think you've missed just how irrelevant kernel version 3.0 really is. To a first approximation, it *has no new features*. Now, to be sure, there are a couple of things, sure. Just like there were a couple new features in 2.6.39 two months earlier, 2.6.38 two months before that, 2.6.37 two months before that, and so on, every 2-3 months, back to the release of 2.6.7 or so in 2004.

I am aware of the history behind that version number change. The
difference between Linux 2.x and 3.x may be small nowadays, but
another 20 kernel releases down the road, the difference will show.

>> BTW: The new attribute should contain the complete version number,
>> not just the major version. `uname -r` would provide a good start.
> 
> To be useful, that would have to be a runtime-computed thing, not the build-time value that sys.platform's trailing number is. But we already have that: os.uname(). It certainly doesn't need a second name.

There are two aspects to consider:

1. The platform Python (and presumably the application) was
   compiled on.

2. The platform Python and the application are currently
   running on.

Both Python and the application will make certain assumptions about
the platform depending on the compile time environment. If the
deployment platform is too different from that environment, it
won't run or not as expected. So you need both the compile and the
runtime version information.

The suggested change removes the compile time information from
the platform string, so that information needs to be preserved
in a new attribute.

As people keep stating how easy the change from sys.platform == 'linux2' to sys.platform.startswith('linux') is, e.g. msg142385, please also keep in mind cases like someDict.get(sys.platform) where the comparison is implicit and therefore a simple change to startswith won't do the trick. Seen that in the wild.

Besides that, I can only wholeheartedly agree to the points so eloquently described by Martin v. Löwis and James Y Knight. Thanks!

Let's please force it to 'linux2' for the next 2.7 and 3.2 releases, so people can use recent kernels without breaking (or having to rewrite) third-party apps. Let's also encourage distros to do the same for older releases, perhaps even suggesting patches.

Marc-Andre Lemburg wrote:
> Both Python and the application will make certain assumptions about
> the platform depending on the compile time environment.

Can you give examples for this?

> So you need both the compile and the runtime version information.

I very much doubt that any feature in Python is actually enabled if
compiled under Linux 3. If so that's probably a bug in Python, due to
the small number of features added from 2.6.39 to 3.0. Either the
feature was introduced into Linux before 3.0, in which case Python
should use it as early as possible, or the feature was introduced in
some 3.x release, in which case not all Linux 3 builds will have it.

So the single digit major number will not be enough for this kind of
checks, and the safest way is to check for the feature itself, e.g. by
simply using it and handling NotImplementedException appropriately. That
approach is more portable for new platforms as well.

Martin von Gagern wrote:
> 
> Martin von Gagern <Martin.vGagern@gmx.net> added the comment:
> 
> Marc-Andre Lemburg wrote:
>> Both Python and the application will make certain assumptions about
>> the platform depending on the compile time environment.
> 
> Can you give examples for this?

Sure, just have a look at how different the various minor release
Mac OS X versions are. They even changed the default architecture
without bumping the major version of the OS.

A configure run on one OS version will pick up different
environment settings than on a later one. As a result Python
and application extensions use different libs/packages/tools
or even create completely different runtimes (e.g. one for PPC,
the other for i386).

>> So you need both the compile and the runtime version information.
> 
> I very much doubt that any feature in Python is actually enabled if
> compiled under Linux 3. If so that's probably a bug in Python, due to
> the small number of features added from 2.6.39 to 3.0. Either the
> feature was introduced into Linux before 3.0, in which case Python
> should use it as early as possible, or the feature was introduced in
> some 3.x release, in which case not all Linux 3 builds will have it.
> 
> So the single digit major number will not be enough for this kind of
> checks, and the safest way is to check for the feature itself, e.g. by
> simply using it and handling NotImplementedException appropriately. That
> approach is more portable for new platforms as well.

That works fine for features that you can programmatically
control. It doesn't work well for static data that you provide
externally depending on the platform OS version. Take e.g.
the plat-freebsdN directories with the OS dependent
constants/functions as example.

As already mentioned, the diff between Linux 2.x and 3.x will
grow over time and while there may not be much to see now,
things will change in the coming years.

Just look at the differences between plat-linux1 and plat-linux2
(plat-linux1 was phased out in Python 2.4 so you have to go back
to Python 2.3 or earlier).

> The suggested change removes the compile time information from
> the platform string, so that information needs to be preserved
> in a new attribute.

-1 on any new platform identification attribute. We already have too
many of them, and there's the platform module for precise
identification.

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> The suggested change removes the compile time information from
>> the platform string, so that information needs to be preserved
>> in a new attribute.
> 
> -1 on any new platform identification attribute. We already have too
> many of them, and there's the platform module for precise
> identification.

Please reread the quoted sentence:

The *compile time* version information needs to be preserved.

The platform module provide *run-time* information, but doesn't
give access to the compile time information.

We do have distutils to read the full compile time information,
but it's not always available, since it often requires installing
development packages.

> We do have distutils to read the full compile time information
We have sysconfig in the stdlib in 2.7 and 3.2+.

Éric Araujo wrote:
> 
> Éric Araujo <merwok@netwok.org> added the comment:
> 
>> We do have distutils to read the full compile time information
> We have sysconfig in the stdlib in 2.7 and 3.2+.

Right (it originated in distutils), but it has the same problem:
without the Makefile and pyconfig.h files installed, it cannot
do its magic.

In addition to that it has the same problem as the platform module:
getting the information can be time and resource consuming.

> Please reread the quoted sentence:
> 
> The *compile time* version information needs to be preserved.

Then please give it a very explicit name, such as "sys.build_platform"
or "sys.compile_time_version_info". We don't want people to be misled by
yet another platform identification attribute.

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> Please reread the quoted sentence:
>>
>> The *compile time* version information needs to be preserved.
> 
> Then please give it a very explicit name, such as "sys.build_platform"
> or "sys.compile_time_version_info". We don't want people to be misled by
> yet another platform identification attribute.

Good idea.

We could simply write `uname -s -r -m` into the new attribute:

sys.build_platform = ('Linux', '2.6.34.8-0.2-desktop', 'x86_64')

and then have

sys.platform = 'linux'

for quick general platform checks.

YAGNI. Nobody has needed sys.build_platform yet. (And no, sys.platform isn't it, since that's been fixed at linux2 approximately forever). Why do you think people would suddenly start needing to know the build-time kernel version now?

James Y Knight wrote:
> 
> YAGNI. Nobody has needed sys.build_platform yet. (And no, sys.platform isn't it, since that's been fixed at linux2 approximately forever). Why do you think people would suddenly start needing to know the build-time kernel version now?

Because it's been integrated to sys.platform for years and on many
platforms. If we now plan to remove it, the information has to be
available from somewhere else, hence the new attribute.

Note that I'm talking about removing it for all platforms, not just
Linux, which has had the major version 2 number for 15 years, but
also for FreeBSD which releases new major versions far more
frequently. The new attribute also helps on Mac OS X and Linux,
since it includes the minor version as well.

BTW: Your "forever" is a rather short time period - Python predates
Linux :-)

It's really hard to follow this issue. I'm trying to sum up, please comment my message if I'm wrong.

--

If I understood correctly, this issue has 3 remaining points:

(1) Python 2.7 and 3.2: force sys.platform to 'linux2'? Votes:

Antoine Pitrou: -1
Victor Stinner: +0
Martin von Gagern: +1
Barry A. Warsaw: +1
Martin v. Löwis: +1
Marc-Andre Lemburg: +1

=> total=+3 (6 votes)

(2) Python 3.3: change sys.platform to 'linux'? Votes:

Martin v. Löwis: +1
Charles-François Natali: -1
Amaury Forgeot d'Arc: -1
Antoine Pitrou: -0 ?
Victor Stinner: +1

=> total=0 (5 votes)

(3) Python 3.3: if point (2) is accepted, add a new variable providing more information about the build platform

--

For the first point, it looks like most people agree to keep 'linux2' on Linux 3 for Python 2.7 and 3.2. I converted Matthias Klose's patch (msg140061) into a patch for Python 3.2: configure_linux2.python3.2.patch. If this patch is accepted, changesets 69dd70e70cc8 (2.7) and 9e3b28a7898f (3.2) have to be reverted (issue #12571).

I prefer to do nothing for (1), but users usually prefer software that "just work". Example: see Arch Linux fiasco when they chose to use Python 3 for /usr/bin/python. Some distro (Debian and Ubuntu?) will anyway use this approach.

--

For the second point, there is no consensus.

I changed my vote from -1 to +1 because... I would like to close the issue (!) and I agree that I will easier to manipulate 'linux' instead of 'linux2' or 'linux3' or 'linux4' or ... (we have such problem today with freebsd2..freebsd8).

--

For the last point, point (3): I think that it would be easier to wait until the point (2) is decided, because the point (3) depends on point (2).

@Marc-Andre Lemburg: you might open a different issue (when point 2 will be deciced)? I consider that it is a different topic because sysconfig already contains requested informations and so it's more a new feature.

MAL wrote:

> As already mentioned, the diff between Linux 2.x and 3.x will
> grow over time and while there may not be much to see now,
> things will change in the coming years.

The only way I can read this argument that makes any sense to me is that you are arguing for a precise build-time OS string.  If it is supposed to be an argument in favor of keeping 'linux3' it makes no sense, since '2' vs '3' is in no way a useful line of demarcation when it comes to linux.

So, if you think there is a *run time* need to know the precise *build time* OS version number, can you point to any specific use cases?

On Aug 19, 2011, at 02:23 PM, STINNER Victor wrote:

>(2) Python 3.3: change sys.platform to 'linux'? Votes:
>
>Martin v. Löwis: +1
>Charles-François Natali: -1
>Amaury Forgeot d'Arc: -1
>Antoine Pitrou: -0 ?
>Victor Stinner: +1
>
>=> total=0 (5 votes)

Please add my +1 to this tally.

>(3) Python 3.3: if point (2) is accepted, add a new variable providing more
>information about the build platform

I'm -0 on this.  I think we either have enough information already, or YAGNI.

>For the second point, there is no consensus.

Maybe I tipped it over. :)

> configure_linux2.python3.2.patch

It would probably be more future-proof to use "linux*)", not "linux3)" in the case expression.

> Python 2.7 and 3.2: force sys.platform to 'linux2'?
-0.  I dislike this change for stable releases, but it’s a small change that would help a lot of users.  I think the release managers would need to approve such a change.

> Python 3.3: change sys.platform to 'linux'?
+1!

> Python 3.3: if point (2) is accepted, add a new variable providing
> more information about the build platform
-0.

BTW, your tallies are wrong: a +0 is more supportive than a -0, but your additions don’t show that.  :)

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> It's really hard to follow this issue. I'm trying to sum up, please comment my message if I'm wrong.
> 
> --
> 
> If I understood correctly, this issue has 3 remaining points:
> 
> (1) Python 2.7 and 3.2: force sys.platform to 'linux2'? Votes:
> 
> Antoine Pitrou: -1
> Victor Stinner: +0
> Martin von Gagern: +1
> Barry A. Warsaw: +1
> Martin v. Löwis: +1
> Marc-Andre Lemburg: +1

I voted -1 on this, not +1. For existing releases, we cannot change
the value of the sys variable and as explained this is not needed
either. IMHO, it's better to fix the few cases in Python that use
'linux2' to also include 'linux3' (either literally or via
.startswith()) and also add a plat-linux3/ dir.

> => total=+3 (6 votes)
> 
> (2) Python 3.3: change sys.platform to 'linux'? Votes:
> 
> Martin v. Löwis: +1
> Charles-François Natali: -1
> Amaury Forgeot d'Arc: -1
> Antoine Pitrou: -0 ?
> Victor Stinner: +1

I voted +1 on this one.

I also suggested to apply the version removal to all platforms,
not just Linux.

> => total=0 (5 votes)
> 
> (3) Python 3.3: if point (2) is accepted, add a new variable providing more information about the build platform
> 
> --
> 
> For the first point, it looks like most people agree to keep 'linux2' on Linux 3 for Python 2.7 and 3.2. I converted Matthias Klose's patch (msg140061) into a patch for Python 3.2: configure_linux2.python3.2.patch. If this patch is accepted, changesets 69dd70e70cc8 (2.7) and 9e3b28a7898f (3.2) have to be reverted (issue #12571).
> 
> I prefer to do nothing for (1), but users usually prefer software that "just work". Example: see Arch Linux fiasco when they chose to use Python 3 for /usr/bin/python. Some distro (Debian and Ubuntu?) will anyway use this approach.
> 
> --
> 
> For the second point, there is no consensus.
> 
> I changed my vote from -1 to +1 because... I would like to close the issue (!) and I agree that I will easier to manipulate 'linux' instead of 'linux2' or 'linux3' or 'linux4' or ... (we have such problem today with freebsd2..freebsd8).
> 
> --
> 
> For the last point, point (3): I think that it would be easier to wait until the point (2) is decided, because the point (3) depends on point (2).
> 
> @Marc-Andre Lemburg: you might open a different issue (when point 2 will be deciced)? I consider that it is a different topic because sysconfig already contains requested informations and so it's more a new feature.

That would make sense, except that I view the removal of the
version and the addition of the compile time information as one
feature request. Moving this off to the sysconfig is not realistic
as mentioned before and the new variable doesn't really cost much
in terms maintenance, since it can be auto-generated by configure.

Note that PyPy is also affected by this issue; see https://bugs.pypy.org/issue832

For CPython, I'm of the opinion that:
  - the final digit of sys.platform as-is for "linux*" is effectively meaningless
  - that no code should be relying on the final digit of sys.platform (thankfully this is now recommended by: http://docs.python.org/library/sys.html#sys.platform )
  - unfortunately there is code out there that checks against "linux2" and thus does rely on this value
  - patching CPython to force this to read "linux2" may be necessary for some downstream distributors of Python, to maximize compatibility with such broken code.

For CPython, "sys.platform" currently reports on the difference between whether "uname" reported linux2 or linux3 at build time, which is currently meaningless (see msg142219 above about our chroot-ed build environment).

For example, in RHEL we may at some future time upgrade our build farm to linux 3, but still provision our build trees within it for linux 2; this may mean that our build farm starts reporting "linux3" when rebuilding security updates for python 2.2, 2.3, 2.4 or 2.6, even when building against kernel-2.*'s user-space.   If this happens, I'd be inclined to patch those builds of Python back to "linux2".  It would be entirely meaningless and only damaging for one of our security updates of, say, Python 2.2 to shift sys.platform from "linux2" to "linux3" simply because of the kernel that was running in the build environment (as opposed to the kernel headers exposed to the compiler, and other such aspects of the kernel exposed in user-space).

FWIW, my opinion is currently:
  - in 3.3, sys.platform on linux should be simply "linux"
  - for 2.7 and 3.2, sys.platform should be forced to "linux2" (and indeed, I anticipate doing this for earlier releases that I still maintain downstream)
  - existing documentation should say that on linux, sys.platform begins with "linux", and that programmers should avoid relying upon the suffix
  - I don't see the need for more adding access to more details of the build platform (and I can poke holes in any such plan, if anyone wants me to: what would it contain?  what about the case where the user-space files e.g. headers aren't the same as the uname?  etc)

R. David Murray wrote:
> 
> R. David Murray <rdmurray@bitdance.com> added the comment:
> 
> MAL wrote:
> 
>> As already mentioned, the diff between Linux 2.x and 3.x will
>> grow over time and while there may not be much to see now,
>> things will change in the coming years.
> 
> The only way I can read this argument that makes any sense to me is that you are arguing for a precise build-time OS string.  If it is supposed to be an argument in favor of keeping 'linux3' it makes no sense, since '2' vs '3' is in no way a useful line of demarcation when it comes to linux.

Indeed. See the sys.build_platform attribute we discussed.

> So, if you think there is a *run time* need to know the precise *build time* OS version number, can you point to any specific use cases?

I already mentioned those use cases. Please see the ticket discussion.

>> The only way I can read this argument that makes any sense to me is
>> that you are arguing for a precise build-time OS string.  If it is
>> supposed to be an argument in favor of keeping 'linux3' it makes no
>> sense, since '2' vs '3' is in no way a useful line of demarcation
>> when it comes to linux.

The build time Linux kernel has no effect on Python's build procedure
whatsoever. Python does not use the kernel at all for building; it
only uses the C library headers, and the kernel headers that happen
to be incorporated into the version of the C library installed. That
affects what features get selected during build time.

Notice that the proposed fix to keep os.platform to "linux2" actually
means that there is *no change*, as os.platform always was "linux2"
on the system. It is a bug that it reports "linux3" in some cases,
and that bug is being fixed.

> The build time Linux kernel has no effect on Python's build procedure
> whatsoever. Python does not use the kernel at all for building; it
> only uses the C library headers, and the kernel headers that happen
> to be incorporated into the version of the C library installed. That
> affects what features get selected during build time.

would be very nice, but unfortunately this is not true; the multiprocessing behavior depends on configure checks testing the running kernel.

Martin v. Löwis wrote:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
>>> The only way I can read this argument that makes any sense to me is
>>> that you are arguing for a precise build-time OS string.  If it is
>>> supposed to be an argument in favor of keeping 'linux3' it makes no
>>> sense, since '2' vs '3' is in no way a useful line of demarcation
>>> when it comes to linux.
> 
> The build time Linux kernel has no effect on Python's build procedure
> whatsoever. Python does not use the kernel at all for building; it
> only uses the C library headers, and the kernel headers that happen
> to be incorporated into the version of the C library installed. That
> affects what features get selected during build time.

That last sentence contradicts the first one. In any case, you're right:
the OS build version does affect the Python build. And not only on
Linux, but on all OSes Python runs on.

That said, the changes on Linux that affect Python are minimal compared
to what other vendors do for even minor OS releases, e.g. Apple with
Mac OS X.

> Notice that the proposed fix to keep os.platform to "linux2" actually
> means that there is *no change*, as os.platform always was "linux2"
> on the system. It is a bug that it reports "linux3" in some cases,
> and that bug is being fixed.

There are Linux 2.x systems out there that report sys.platform ==
'linux3' ? :-)

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

New changeset c816479f6aaf by Victor Stinner in branch '2.7':
Issue #12326: sys.platform is now always 'linux2' on Linux
http://hg.python.org/cpython/rev/c816479f6aaf

I'm working on a patch to remove the major version of sys.platform. The patch is much bigger than expected. You will see when it will be done :-)

> I'm working on a patch to remove the major version of sys.platform

As expected by Marc-Andre: we need this information and so it has to be available somewhere else. I created #12794 to add platform.major(). I prefer to get the major version at runtime, not the major version used to build Python. I need the major version for Python tests: the tests checks features of the running system (kernel), not of the system used to build Python.

@Marc-Andre Lemburg: If you still think that we need all information about the system used to build Python, please open another issue (or comment maybe #12794).

> I'm working on a patch to remove the major version of sys.platform

Done. I created the issue #12795: "Remove the major version from sys.platform".

New changeset b072e1559d6b by Victor Stinner in branch 'default':
Close #12326: sys.platform is now always 'linux' on Linux
http://hg.python.org/cpython/rev/b072e1559d6b

For the sys.build_info, I opened #12794 (platform.major()) but then quickly closed it because it was only useful if the issue #12795 (Remove the major version from sys.platform) was accepted, but I closed it.

--

Update votes for "(2) Python 3.3: change sys.platform to 'linux'":

Charles-François Natali: -1
Amaury Forgeot d'Arc: -1

Antoine Pitrou: +1
Barry A. Warsaw: +1
Éric Araujo: +1
Dave Malcolm: +1
Marc-Andre Lemburg: +1
Martin v. Löwis: +1
Victor Stinner: +1

=> total=+5 (9 votes)

The changeset b072e1559d6b (sys.platform is now always 'linux') closes this issue because it solves the initial problem. Did you notice how trivial is the final patch? ;-)

This funny issue is closed, we can now work again on real bugs :-)

New changeset 85e091c83f9a by Victor Stinner in branch 'default':
Issue #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 #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 #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 #12795 for other platforms.

In case of plat-* directories, please see issue #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 #12795 which has a well defined title. This issue is closed. (#12795 has also a patch) Well, #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 #12795 which has a well defined title. This issue is closed. (#12795 has also a patch) Well, #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 #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 #12326.
http://hg.python.org/cpython/rev/e11b4c945f7e

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

New changeset cb47cf5138a4 by Victor Stinner in branch '3.2':
Issue #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 #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.