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.