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.