-
-
Notifications
You must be signed in to change notification settings - Fork 30.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux 3: code should avoid using sys.platform == 'linux2' #56535
Comments
Linus recently decided that the next Linux kernel version would 3.0 [1]. """ |
Why should be used instead?
Tests like sys.platform in ('linux2', 'darwin') can be replaced by sys.platform in ('linux2', 'linux3', 'darwin'). We will have to patch this test again for Linux 4. |
I would expect changing sys.platform will also break a lot of third-party code. Perhaps sys.platform can still be 'linux2' under Linux 3.x? After all, there's no significant change that deserves changing sys.platform. |
sys.platform comes from Py_GetPlatform() which comes from PLATFORM define. On Linux, this define comes from Makefile: MACHDEP variable which comes from configure. Finally, MACHDEP is defined by:
|
Maybe, but this would be an application bug. Here's sys.platform current implementation: const char *
Py_GetPlatform(void)
{
return PLATFORM;
} And here's the documentation, from http://docs.python.org/c-api/init.html """ So it's actually documented.
Sounds like a recipe for confusion. |
I suggest to change sys.platform to 'linux' in future releases (3.3). For bugfix releases (2.7, 3.2), I'd keep it as 'linux2' even on Linux 3. For security-only releases (2.6, 3.1), no change should be made. |
This change is reasonable for the long term. But it *will* break a lot of code. |
[If you favor a specific change, please indicate what that is. I'm I agree it will break a lot of code, but it's also somewhat urgent It's important that we set a policy before the Linux distributions |
The change to sys.platform=='linux' would break code even on current platforms. |
Correct. Compared to introducing 'linux3', I consider this the better
While this has better compatibility, it's also a constant source of I personally disliked 'linux2' when it was introduced, for its |
Any application relying on sys.platform == 'linux2' is already broken. |
Martin v. Löwis wrote:
I think we should consider adding a better mechanism and just sys.system == 'linux', 'freebsd', 'openbsd', 'windows', etc. and a new sys.system_info == system release info (named) tuple similar to to query a specific system version. As already noted, direct sys.platform testing already breaks for |
FWIW, I also agree that sys.platform == 'linux' would be the better |
Martin’s sys.platform = 'linux' sounds good to me too. |
Just to give some statistic, in Debian we have >80 binary packages that check if sys.platform is linux2. However, it appears to me that vast majority of them is broken anyway, because what they really mean to check is:
|
IOW, they should check os.name == 'posix'? |
That's exactly my point. |
I would agree with this. Perhaps the documentation for sys.platform could be changed to mention that platform.system() should maybe be used instead. |
So people who say sys.platform shouldn't be used: what do you propose to do with Lib/plat-linux2 (or, more generally, Lib/plat-*)? |
What are these directories? Are they still used? |
Look and see for yourself.
Sure. If you do "import DLFCN", it will come from that directory. |
These directories look useless to me. That's orthogonal to whether sys.platform should be used or not, however. We should at least document an example of using sys.platform.startswith() Regards Antoine. |
Indeed, the lib/plat- directories should continue to work just fine using linux3, correct? Or using linux, if we change sys.platform. (Note: just because we don't import them in the test suite doesn't mean that user code in the field isn't using them...I got a few (trivial it is true, but...) hits from google code search on DLFCN.) Changing sys.platform as Martin suggests seems like the least painful solution to me. Note, however, that we have skips in the tests suite that do care about, for example, the FreeBSD OS major version. FreeBSD does sometimes fix the bugs we've discovered...but as someone else pointed out, this doesn't necessarily happen at a major release boundary, we just use that in the test skipping because it is the easiest thing for us to do. If sys.platform no longer included the OS major version, the test skips would probably end up being made more accurate. |
|
I can't speak, as I've never used those. As for the performance overhead, since the platform module caches the result of uname or other function/subprocess calls, I don't think it's a showstopper. Furthermore, I somehow doubt those functions are performance bottlenecks anyway. Since Linux 3 is in RC now, is there a chance to reach a consensus in the near future? |
That would be incorrect for some systems. For example, FreeBSD does
Doesn't look like it. |
Well, I don't see the problem in that case. |
What I'm advocating is to special-case Linux (and any other system
I don't argue with that. I agree the code is broken (although I disagree
Indeed - hence I propose to drop it from sys.platform if the system |
Le Mon, 27 Jun 2011 08:05:05 +0000,
Actually, it would itself break compatibility, because sys.platform would I think we should at least document the idiom of using |
New changeset bf89ff3d1ec9 by Victor Stinner in branch 'default': |
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-freebsd<x>.:
I'm happy to open a new issue discussing this if that's the right thing to do. |
Larry: the scope of this bug was narrowed to the linux breakage only; see bpo-12795 for other platforms. |
In case of plat-* directories, please see issue bpo-12619, which proposes some changes. |
I agree that's definitely out of scope of this issue.
Definitely not. The reasoning that applies to Linux doesn't necessarily |
Where's the doc updates for the stable branches? Also, we might think about removing this version number everywhere. |
I don't know how to update this documentation. Can someone update the
Please, see my issue http://bugs.python.org/issue12795 for this topic. |
Georg Brandl wrote:
+1 |
Martin v. Löwis wrote:
We could change the title of the ticket :-)
Actually, with that reasoning we would need to reintroduce the IMO, a better approach is to split the information in two parts:
|
STINNER Victor wrote:
Ok, I moved the discussion there. |
Please keep the issue closed... The issue at hand was that Linux 3 For the other platforms, I don't see any issue to be fixed (except |
This is a strange statement. You changed the implementation, so you should be able to change the documentation accordingly. |
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:
================ ===========================
? I don't think that I need a :versionchanged:`2.7.3`. |
I think the doc patch should mention that:
|
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. |
Please delete Lib/plat-linux3 directories on 2.7 and 3.2 branches. |
New changeset 265da863d017 by Victor Stinner in branch '3.2': New changeset e11b4c945f7e by Georg Brandl in branch '3.2': |
New changeset d95c4b030eac by Victor Stinner in branch '2.7': New changeset cb47cf5138a4 by Victor Stinner in branch '3.2': |
New changeset 0fe571d43317 by Victor Stinner in branch '2.7': |
I removed Lib/plat-linux3 from Python 2.7 and 3.2, and updated doc of Python 2.7. I close this issue (again). |
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? |
On Oct 04, 2011, at 01:03 PM, Boštjan Mejak wrote:
Python 3.3 already sets sys.platform to 'linux'. It can't be done for older |
'linux2' used to refer to the Linux 2.X kernel, but sys.platform was changed to just 'linux' for all kernel versions since Python 3.3 circa 2011. See also: python/cpython#56535
'linux2' used to refer to the Linux 2.X kernel, but sys.platform was changed to just 'linux' for all kernel versions since Python 3.3 circa 2011. See also: python/cpython#56535
'linux2' used to refer to the Linux 2.X kernel, but sys.platform was changed to just 'linux' for all kernel versions since Python 3.3 circa 2011. See also: python/cpython#56535
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: