Dave Malcolm <dmalc...@redhat.com> added the comment: 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) ---------- _______________________________________ 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
