Marc-Andre Lemburg <m...@egenix.com> added the comment: James Y Knight wrote: > > James Y Knight <f...@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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12326> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
