[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Boštjan Mejak bostjan.me...@gmail.com added the comment: 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? -- nosy: +Retro ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: 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 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 0fe571d43317 by Victor Stinner in branch '2.7': Update sys.platform doc for #12326. http://hg.python.org/cpython/rev/0fe571d43317 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: I removed Lib/plat-linux3 from Python 2.7 and 3.2, and updated doc of Python 2.7. I close this issue (again). -- status: open - closed ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: 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 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Georg Brandl ge...@python.org added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment: Please delete Lib/plat-linux3 directories on 2.7 and 3.2 branches. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: Georg Brandl wrote: Also, we might think about removing this version number everywhere. +1 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: Martin v. Löwis wrote: Martin v. Löwis mar...@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) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@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 :-) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Georg Brandl ge...@python.org added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment:
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`.
--
___
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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Ezio Melotti ezio.melo...@gmail.com added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Georg Brandl ge...@python.org added the comment: 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. -- status: closed - open ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by Georg Brandl ge...@python.org: -- priority: normal - release blocker ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset bf89ff3d1ec9 by Victor Stinner in branch 'default': Issue #12326: update sys.platform doc for Linux http://hg.python.org/cpython/rev/bf89ff3d1ec9 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Larry Hastings la...@hastings.org added the comment: 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-freebsdx.: * Move the all existing plat-freebsdx/IN.py to plat-freebsd/INx.py * Write a new plat-freebsd/IN.py that uses sys.platform_version to read in the correct INx.py. * Alter plat-freebsd/regen to generate INx.py I suspect plat-freebsdx 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. -- nosy: +larry ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Éric Araujo mer...@netwok.org added the comment: Larry: the scope of this bug was narrowed to the linux breakage only; see #12795 for other platforms. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com added the comment: In case of plat-* directories, please see issue #12619, which proposes some changes. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@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. 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). -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Georg Brandl ge...@python.org added the comment: Where's the doc updates for the stable branches? Also, we might think about removing this version number everywhere. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: 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 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: 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 :-) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: 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). -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: 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 -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: 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 :-) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: 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 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset b5ccdf7c032a by Victor Stinner in branch 'default': Issue #12326: refactor usage of sys.platform http://hg.python.org/cpython/rev/b5ccdf7c032a -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin von Gagern martin.vgag...@gmx.net added the comment:
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.
--
___
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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin von Gagern martin.vgag...@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? 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: Martin von Gagern wrote: Martin von Gagern martin.vgag...@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). -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Antoine Pitrou pit...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: Antoine Pitrou pit...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Éric Araujo mer...@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+. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: Éric Araujo wrote: Éric Araujo mer...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Antoine Pitrou pit...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@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.
--
___
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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight f...@users.sourceforge.net added the comment: 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? -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: 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 :-) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@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 = 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. -- Added file: http://bugs.python.org/file22946/configure_linux2.python3.2.patch ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
R. David Murray rdmur...@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. 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? -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: 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. :) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight f...@users.sourceforge.net added the comment: configure_linux2.python3.2.patch It would probably be more future-proof to use linux*), not linux3) in the case expression. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Éric Araujo mer...@netwok.org added the comment: 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. :) -- nosy: +benjamin.peterson, georg.brandl ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: R. David Murray wrote: R. David Murray rdmur...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@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. 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Matthias Klose d...@debian.org added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: Martin v. Löwis wrote: Martin v. Löwis mar...@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' ? :-) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Charles-François Natali neolo...@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. 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: On Aug 18, 2011, at 01:15 PM, Charles-François Natali wrote: Charles-François Natali neolo...@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 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: 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 :-)) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: 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) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@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.)? -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: On Aug 18, 2011, at 03:58 PM, STINNER Victor wrote: STINNER Victor victor.stin...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Antoine Pitrou pit...@free.fr added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: For Python 3.3, (...) In parallel we can change the stdlib tests to use .startswith() done, see my changeset 50f1922bc1d5 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by Charles-François Natali neolo...@free.fr: -- nosy: -neologix ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight f...@users.sourceforge.net added the comment: 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 Python2.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 Python2.7.3 which have had the same fix backported to them by distros, since Python upstream won't do it for earlier branches. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: - 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Antoine Pitrou pit...@free.fr added the comment: 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). -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Antoine Pitrou pit...@free.fr added the comment: 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). -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Antoine Pitrou pit...@free.fr added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: 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? -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight f...@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. 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: James Y Knight wrote: James Y Knight f...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: Barry A. Warsaw wrote: Barry A. Warsaw ba...@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 ;-) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
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. 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Charles-François Natali neolo...@free.fr added the comment: 2011/8/16 Dave Malcolm rep...@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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: 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 -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: New changeset 50f1922bc1d5 by Victor Stinner in branch 'default': I will backport the fix to 2.7 and 3.2. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight f...@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? -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: On Aug 18, 2011, at 01:20 AM, James Y Knight wrote: James Y Knight f...@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'. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@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 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. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Sandro Tosi sandro.t...@gmail.com added the comment: On Tue, Aug 16, 2011 at 16:21, Barry A. Warsaw rep...@bugs.python.org wrote: Barry A. Warsaw ba...@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) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: 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) -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Dave Malcolm dmalc...@redhat.com added the comment: 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 -cimport 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%20start=50order=nvrtype=component [2] http://kojipkgs.fedoraproject.org/packages/python/2.7.2/4.fc16/data/logs/x86_64/build.log -- nosy: +dmalcolm ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: 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. -- Added file: http://bugs.python.org/file22917/linux3-v2.patch ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by STINNER Victor victor.stin...@haypocalc.com: Removed file: http://bugs.python.org/file22613/linux3.patch ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by Martin von Gagern martin.vgag...@gmx.net: -- nosy: +gagern ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Sandro Tosi sandro.t...@gmail.com added the comment: On Mon, Jul 25, 2011 at 13:50, Éric Araujo rep...@bugs.python.org wrote: Éric Araujo mer...@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. -- nosy: +sandro.tosi ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight f...@users.sourceforge.net added the comment: 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*? -- nosy: +foom ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Éric Araujo mer...@netwok.org added the comment: FTR, for Debian and derivatives, doko chose to use 'linux2' when building on linux3. -- title: Linux 3: tests should avoid using sys.platform == 'linux2' - Linux 3: code should avoid using sys.platform == 'linux2' versions: -Python 3.4 ___ 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
