Skip to content
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

Closed
neologix mannequin opened this issue Jun 13, 2011 · 145 comments
Closed

Linux 3: code should avoid using sys.platform == 'linux2' #56535

neologix mannequin opened this issue Jun 13, 2011 · 145 comments
Labels
release-blocker type-bug An unexpected behavior, bug, or error

Comments

@neologix
Copy link
Mannequin

neologix mannequin commented Jun 13, 2011

BPO 12326
Nosy @malemburg, @loewis, @warsaw, @birkenfeld, @doko42, @amauryfa, @pitrou, @vstinner, @larryhastings, @benjaminp, @jwilk, @djc, @ezio-melotti, @merwok, @bitdancer, @davidmalcolm, @sandrotosi, @akheron
Files
  • linux3-v2.patch
  • configure_linux2.python3.2.patch
  • 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:

    assignee = None
    closed_at = <Date 2011-09-05.20:39:30.835>
    created_at = <Date 2011-06-13.14:34:41.657>
    labels = ['type-bug', 'release-blocker']
    title = "Linux 3: code should avoid using sys.platform == 'linux2'"
    updated_at = <Date 2011-10-04.14:24:53.642>
    user = 'https://bugs.python.org/neologix'

    bugs.python.org fields:

    activity = <Date 2011-10-04.14:24:53.642>
    actor = 'barry'
    assignee = 'none'
    closed = True
    closed_date = <Date 2011-09-05.20:39:30.835>
    closer = 'vstinner'
    components = []
    creation = <Date 2011-06-13.14:34:41.657>
    creator = 'neologix'
    dependencies = []
    files = ['22917', '22946']
    hgrepos = []
    issue_num = 12326
    keywords = ['patch']
    message_count = 145.0
    messages = ['138251', '138252', '138253', '138254', '138255', '138271', '138294', '138295', '138298', '138299', '138300', '138306', '138308', '138527', '138582', '138597', '138711', '138730', '138757', '138759', '138816', '138817', '138823', '138824', '139166', '139208', '139224', '139243', '139248', '140012', '140017', '140061', '140062', '140063', '140064', '140065', '140394', '140397', '140684', '140703', '140708', '140710', '140801', '140802', '140830', '140831', '140939', '140944', '140949', '140955', '140985', '141088', '141651', '141659', '142195', '142196', '142197', '142219', '142226', '142272', '142290', '142291', '142297', '142298', '142313', '142344', '142345', '142346', '142350', '142353', '142354', '142356', '142358', '142379', '142380', '142381', '142382', '142384', '142385', '142387', '142389', '142394', '142396', '142398', '142401', '142406', '142407', '142408', '142409', '142410', '142417', '142418', '142419', '142420', '142425', '142440', '142441', '142444', '142446', '142450', '142451', '142453', '142457', '142459', '142460', '142461', '142463', '142482', '142490', '142493', '142498', '142499', '142500', '142524', '142531', '142539', '142541', '142570', '142571', '142574', '142579', '142593', '142605', '142614', '142615', '142628', '142635', '142678', '142694', '142697', '142698', '142700', '142707', '142711', '142762', '142766', '142769', '143455', '143470', '143479', '143557', '143561', '143562', '144889', '144890']
    nosy_count = 25.0
    nosy_names = ['lemburg', 'loewis', 'barry', 'georg.brandl', 'doko', 'amaury.forgeotdarc', 'gagern', 'foom', 'pitrou', 'vstinner', 'larry', 'benjamin.peterson', 'jwilk', 'djc', 'ezio.melotti', 'eric.araujo', 'Arfrever', 'Retro', 'r.david.murray', 'dmalcolm', 'sandro.tosi', 'rosslagerwall', 'python-dev', 'petri.lehtinen', 'Ramchandra Apte']
    pr_nums = []
    priority = 'release blocker'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue12326'
    versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

    @neologix
    Copy link
    Mannequin Author

    neologix mannequin commented Jun 13, 2011

    Linus recently decided that the next Linux kernel version would 3.0 [1].
    As a consequence, sys.platform (which is actually MACHDEP) will be 'linux3' on machines running Linux 3 kernels, and tests checking explicitely against 'linux2' will either break and won't run.
    A quick grep through the code base returns only a couple problematic places, but this should definitely be fixed.
    For information, here's a - probably incomplete - list of such occurrences:

    """
    ./Lib/test/test_logging.py: if sys.platform in ('linux2', 'darwin'):
    ./Lib/test/test_sysconfig.py: sys.platform = 'linux2'
    ./Lib/test/regrtest.py: 'linux2':
    ./Lib/test/test_socket.py: if sys.platform == 'linux2':
    ./Lib/test/test_tarfile.py: if sys.platform == "linux2":
    ./Lib/distutils/tests/test_bdist_rpm.py: if sys.platform != 'linux2':
    ./Lib/distutils/tests/test_bdist_rpm.py: if sys.platform != 'linux2':
    ./Lib/distutils/tests/test_util.py: sys.platform = 'linux2'
    ./Lib/packaging/tests/test_config.py: inotify (0.0.1); sys.platform == 'linux2'
    ./Lib/packaging/tests/test_config.py: "inotify (0.0.1); sys.platform == 'linux2'"]
    ./setup.py: if (platform in ('linux2', 'freebsd4', 'freebsd5', 'freebsd6',
    """

    [1] http://thread.gmane.org/gmane.linux.kernel/1147415

    @neologix neologix mannequin added the type-bug An unexpected behavior, bug, or error label Jun 13, 2011
    @vstinner
    Copy link
    Member

    Why should be used instead?

    • sys.platform.startswith('linux')
    • os.uname()[0] == 'Linux'
    • platform.system() == 'Linux'
    • other?

    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.

    @pitrou
    Copy link
    Member

    pitrou commented Jun 13, 2011

    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.

    @vstinner
    Copy link
    Member

    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:

    ac_sys_system=`uname -s`
    if test "$ac_sys_system" = "AIX" \
    -o "$ac_sys_system" = "UnixWare" -o "$ac_sys_system" = "OpenUNIX"; then
    	ac_sys_release=`uname -v`
    else
    	ac_sys_release=`uname -r`
    fi
    ac_md_system=`echo $ac_sys_system |
    		   tr -d '/ ' | tr '[A-Z]' '[a-z]'`
    ac_md_release=`echo $ac_sys_release |
    		   tr -d '/ ' | sed 's/^[A-Z]\.//' | sed 's/\..*//'`
    MACHDEP="$ac_md_system$ac_md_release"
    

    @neologix
    Copy link
    Mannequin Author

    neologix mannequin commented Jun 13, 2011

    I would expect changing sys.platform will also break a lot of third-
    party code.

    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

    """
    Return the platform identifier for the current platform. On Unix, this is formed from the “official” name of the operating system, converted to lower case, followed by the major revision number"""

    So it's actually documented.

    Perhaps sys.platform can still be 'linux2' under Linux 3.x? After
    all, there's no significant change that deserves changing
    sys.platform.

    Sounds like a recipe for confusion.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 13, 2011

    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.

    @amauryfa
    Copy link
    Member

    This change is reasonable for the long term. But it *will* break a lot of code.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 14, 2011

    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
    assuming you support my proposal for the moment :-]

    I agree it will break a lot of code, but it's also somewhat urgent
    because we will get 'linux3' if we don't act, which will also break
    a lot of code (but more subtly, since people testing their code may
    do so on Linux 2, only to get bug reports that it breaks on "some"
    Linux systems). I'm sure Linus Torvalds is fully aware of the possible
    consequences of the version change, and just accepted the breakage
    that this would cause.

    It's important that we set a policy before the Linux distributions
    do (which may end up choosing different policies). We don't actually
    have to *release* this change quickly, since Linux distributions
    who release 3.x kernels will fix their Python packages themselves.

    @amauryfa
    Copy link
    Member

    The change to sys.platform=='linux' would break code even on current platforms.
    OTOH, we have sys.platform=='win32' even on Windows 64bit; would this favor keeping 'linux2' on all versions of Linux as well?

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 14, 2011

    The change to sys.platform=='linux' would break code even on current platforms.

    Correct. Compared to introducing 'linux3', I consider this the better
    change - it likely breaks earlier (i.e. when porting to Python 3.3).

    OTOH, we have sys.platform=='win32' even on Windows 64bit; would this
    favor keeping 'linux2' on all versions of Linux as well?

    While this has better compatibility, it's also a constant source of
    irritation. Introducing 'win64' would have been a worse choice (just
    as introducing 'linux3' would: incompatibility for no gain, since
    the distinction between win32 and win64, from a Python POV, is
    irrelevant). Plus, Microsoft dislikes the term Win64 somewhat, and
    rather wants people to refer to the "Windows API".

    I personally disliked 'linux2' when it was introduced, for its
    incompatibilities. Anticipating that, some day, we may have 'Linux 4',
    and so on, I still claim it is better to fix this now. We could even
    come up with a 2to3 fixer for people who dual-source their code.

    @neologix
    Copy link
    Mannequin Author

    neologix mannequin commented Jun 14, 2011

    I'm sure Linus Torvalds is fully aware of the possible
    consequences of the version change, and just accepted the breakage
    that this would cause.

    Any application relying on sys.platform == 'linux2' is already broken.
    It's exactly the same if an application checks for 'freebsd6' or
    'openbsd4' : if you want to check for a specific operating system,
    there's already POSIX' struct utsname sysname field, i.e. uname()[0].

    @malemburg
    Copy link
    Member

    Martin v. Löwis wrote:

    Martin v. Löwis <martin@v.loewis.de> added the comment:

    > The change to sys.platform=='linux' would break code even on current platforms.

    Correct. Compared to introducing 'linux3', I consider this the better
    change - it likely breaks earlier (i.e. when porting to Python 3.3).

    > OTOH, we have sys.platform=='win32' even on Windows 64bit; would this
    > favor keeping 'linux2' on all versions of Linux as well?

    While this has better compatibility, it's also a constant source of
    irritation. Introducing 'win64' would have been a worse choice (just
    as introducing 'linux3' would: incompatibility for no gain, since
    the distinction between win32 and win64, from a Python POV, is
    irrelevant). Plus, Microsoft dislikes the term Win64 somewhat, and
    rather wants people to refer to the "Windows API".

    I personally disliked 'linux2' when it was introduced, for its
    incompatibilities. Anticipating that, some day, we may have 'Linux 4',
    and so on, I still claim it is better to fix this now. We could even
    come up with a 2to3 fixer for people who dual-source their code.

    I think we should consider adding a better mechanism and just
    keep the old mechanism for determining sys.platform in place
    (letting it break on Linux to raise awareness) and add a new better
    attribute along the lines of what Martin suggested:

    sys.system == 'linux', 'freebsd', 'openbsd', 'windows', etc.
    (without version)

    and a new

    sys.system_info == system release info (named) tuple similar to
    sys.version_info

    to query a specific system version.

    As already noted, direct sys.platform testing already breaks for
    OpenBSD, FreeBSD and probably a few other OSes as well with
    every major OS release, so the Linux breakage is not really new
    in any way.

    @pitrou
    Copy link
    Member

    pitrou commented Jun 14, 2011

    > The change to sys.platform=='linux' would break code even on current platforms.

    Correct. Compared to introducing 'linux3', I consider this the better
    change - it likely breaks earlier (i.e. when porting to Python 3.3).

    FWIW, I also agree that sys.platform == 'linux' would be the better
    choice. It seems there's little point having the kernel's major version
    there. It's both disruptive and useless (because features are introduced
    at any point, not just at new major versions).

    @merwok
    Copy link
    Member

    merwok commented Jun 17, 2011

    Martin’s sys.platform = 'linux' sounds good to me too.

    @jwilk
    Copy link
    Mannequin

    jwilk mannequin commented Jun 18, 2011

    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:

    • is this a non-Windows sytem? or
    • is this a UNIX-like system? or
    • is this a system with GNU userland?

    @merwok
    Copy link
    Member

    merwok commented Jun 18, 2011

    IOW, they should check os.name == 'posix'?

    @neologix
    Copy link
    Mannequin Author

    neologix mannequin commented Jun 20, 2011

    However, it appears to me that vast majority of them is broken anyway,
    because what they really mean to check is

    That's exactly my point.
    Code checking sys.platform against 'linux2' is already broken, there's
    no point in complicating the code further, or adding a new constant.
    If you want to check for a specific operating system, there's already
    platform.system().

    @rosslagerwall
    Copy link
    Mannequin

    rosslagerwall mannequin commented Jun 20, 2011

    That's exactly my point.
    Code checking sys.platform against 'linux2' is already broken, there's
    no point in complicating the code further, or adding a new constant.
    If you want to check for a specific operating system, there's already
    platform.system().

    I would agree with this. Perhaps the documentation for sys.platform could be changed to mention that platform.system() should maybe be used instead.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 20, 2011

    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-*)?

    @vstinner
    Copy link
    Member

    what do you propose to do with Lib/plat-linux2
    (or, more generally, Lib/plat-*)?

    What are these directories? Are they still used?

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 22, 2011

    What are these directories?

    Look and see for yourself.

    Are they still used?

    Sure. If you do "import DLFCN", it will come from that directory.

    @pitrou
    Copy link
    Member

    pitrou commented Jun 22, 2011

    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-*)?

    These directories look useless to me.
    (IIRC, putting an obvious syntax error there does not trigger any failure
    in the regression suite, showing that they are never imported)

    That's orthogonal to whether sys.platform should be used or not, however.
    During the language summit, someone (Marc-André) brought an interesting
    point: the platform does external calls to system commands such as "uname",
    which can be time-consuming.

    We should at least document an example of using sys.platform.startswith()
    rather than exact comparison.

    Regards

    Antoine.

    @bitdancer
    Copy link
    Member

    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.

    @merwok
    Copy link
    Member

    merwok commented Jun 22, 2011

    the platform does external calls to system commands such as "uname",
    I guess it’s the platform module.

    @neologix
    Copy link
    Mannequin Author

    neologix mannequin commented Jun 26, 2011

    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-*)?

    I can't speak, as I've never used those.
    But can't those directories be renamed to Lib/plat-<platform.system()>?

    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?

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 26, 2011

    I can't speak, as I've never used those. But can't those directories
    be renamed to Lib/plat-<platform.system()>?

    That would be incorrect for some systems. For example, FreeBSD does
    change sets of symbolic constants across system releases (mostly
    additions, but sometimes also removals). Back then, SunOS 4 and SunOS
    5 were completely unrelated systems.

    Since Linux 3 is in RC now, is there a chance to reach a consensus in
    the near future?

    Doesn't look like it.

    @neologix
    Copy link
    Mannequin Author

    neologix mannequin commented Jun 26, 2011

    That would be incorrect for some systems. For example, FreeBSD does
    change sets of symbolic constants across system releases (mostly
    additions, but sometimes also removals). Back then, SunOS 4 and SunOS
    5 were completely unrelated systems.

    Well, I don't see the problem in that case.
    If what's intended is to target different operating systems releases,
    then sys.platform is the right choice and should be kept, since it
    embeds the major version number.
    The point I (and others) have been trying to make is that 99% of the
    time, people using sys.platform really mean platform.system() or
    uname[0], since they're only interested in the operating system, and
    don't care about the release. That's true of the vast majority of such
    occurrences in Lib/test, and probably true of the vast majority of the
    user code base.
    Furthermore, at least on Linux, the major version number doesn't mean
    anything, since features are added and removed in "minor" versions,
    and Linux 3.0 doesn't have anything special as far as features as
    concerned (as explained by Linus, a version number is just a number).

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Jun 27, 2011

    > That would be incorrect for some systems. For example, FreeBSD does
    > change sets of symbolic constants across system releases (mostly
    > additions, but sometimes also removals). Back then, SunOS 4 and SunOS
    > 5 were completely unrelated systems.
    >

    Well, I don't see the problem in that case.

    What I'm advocating is to special-case Linux (and any other system
    where major version numbers don't mean much).

    The point I (and others) have been trying to make is that 99% of the
    time, people using sys.platform really mean platform.system() or
    uname[0], since they're only interested in the operating system, and
    don't care about the release. That's true of the vast majority of such
    occurrences in Lib/test, and probably true of the vast majority of the
    user code base.

    I don't argue with that. I agree the code is broken (although I disagree
    that platform.system is the right answer in most cases), but that
    doesn't help resolving this issue (unless the resolution is "no change",
    which I still oppose to).

    Furthermore, at least on Linux, the major version number doesn't mean
    anything

    Indeed - hence I propose to drop it from sys.platform if the system
    is Linux.

    @pitrou
    Copy link
    Member

    pitrou commented Jun 27, 2011

    Le Mon, 27 Jun 2011 08:05:05 +0000,
    Martin v. Löwis <report@bugs.python.org> a écrit :

    What I'm advocating is to special-case Linux (and any other system
    where major version numbers don't mean much).

    Actually, it would itself break compatibility, because sys.platform would
    jump from "linux2" to "linux" from one Python release to another. It would
    therefore only be applicable, at best, to 3.3.

    I think we should at least document the idiom of using
    "sys.platform.startswith(...)", and mention the platform module as an
    alternative. This can be done in all doc versions without breaking
    anything, and in time for Linux 3 :)

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Aug 21, 2011

    New changeset bf89ff3d1ec9 by Victor Stinner in branch 'default':
    Issue bpo-12326: update sys.platform doc for Linux
    http://hg.python.org/cpython/rev/bf89ff3d1ec9

    @larryhastings
    Copy link
    Contributor

    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>.:

    • Move the all existing plat-freebsd<x>/IN.py to plat-freebsd/IN<x>.py
    • Write a new plat-freebsd/IN.py that uses sys.platform_version
      to read in the correct IN<x>.py.
    • Alter plat-freebsd/regen to generate IN<x>.py
      I suspect plat-freebsd<x> 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.

    @merwok
    Copy link
    Member

    merwok commented Aug 21, 2011

    Larry: the scope of this bug was narrowed to the linux breakage only; see bpo-12795 for other platforms.

    @Arfrever
    Copy link
    Mannequin

    Arfrever mannequin commented Aug 21, 2011

    In case of plat-* directories, please see issue bpo-12619, which proposes some changes.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Aug 21, 2011

    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).

    @birkenfeld
    Copy link
    Member

    Where's the doc updates for the stable branches?

    Also, we might think about removing this version number everywhere.

    @vstinner
    Copy link
    Member

    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.

    @malemburg
    Copy link
    Member

    Georg Brandl wrote:

    Also, we might think about removing this version number everywhere.

    +1

    @malemburg
    Copy link
    Member

    Martin v. Löwis wrote:

    Martin v. Löwis <martin@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)

    @vstinner
    Copy link
    Member

    We could change the title of the ticket :-)

    No please, move the discussion to bpo-12795 which has a well defined title. This issue is closed. (bpo-12795 has also a patch) Well, bpo-12795 is also close but you can reopen it if you explain why :-)

    @malemburg
    Copy link
    Member

    STINNER Victor wrote:

    STINNER Victor <victor.stinner@haypocalc.com> added the comment:

    > We could change the title of the ticket :-)

    No please, move the discussion to bpo-12795 which has a well defined title. This issue is closed. (bpo-12795 has also a patch) Well, bpo-12795 is also close but you can reopen it if you explain why :-)

    Ok, I moved the discussion there.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Aug 22, 2011

    > 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.

    @birkenfeld
    Copy link
    Member

    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.

    @vstinner
    Copy link
    Member

    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`.

    @ezio-melotti
    Copy link
    Member

    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.

    @birkenfeld
    Copy link
    Member

    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.

    @Arfrever
    Copy link
    Mannequin

    Arfrever mannequin commented Sep 3, 2011

    Please delete Lib/plat-linux3 directories on 2.7 and 3.2 branches.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Sep 4, 2011

    New changeset 265da863d017 by Victor Stinner in branch '3.2':
    Issue bpo-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 bpo-12326.
    http://hg.python.org/cpython/rev/e11b4c945f7e

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Sep 5, 2011

    New changeset d95c4b030eac by Victor Stinner in branch '2.7':
    Issue bpo-12326: Remove plat-linux3 directory
    http://hg.python.org/cpython/rev/d95c4b030eac

    New changeset cb47cf5138a4 by Victor Stinner in branch '3.2':
    Issue bpo-12326: Remove plat-linux3 directory
    http://hg.python.org/cpython/rev/cb47cf5138a4

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Sep 5, 2011

    New changeset 0fe571d43317 by Victor Stinner in branch '2.7':
    Update sys.platform doc for bpo-12326.
    http://hg.python.org/cpython/rev/0fe571d43317

    @vstinner
    Copy link
    Member

    vstinner commented Sep 5, 2011

    I removed Lib/plat-linux3 from Python 2.7 and 3.2, and updated doc of Python 2.7. I close this issue (again).

    @vstinner vstinner closed this as completed Sep 5, 2011
    @Retro
    Copy link
    Mannequin

    Retro mannequin commented Oct 4, 2011

    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?

    @warsaw
    Copy link
    Member

    warsaw commented Oct 4, 2011

    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.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    thewtex added a commit to thewtex/python-cmake-buildsystem that referenced this issue Aug 23, 2024
    '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
    thewtex added a commit to thewtex/python-cmake-buildsystem that referenced this issue Aug 24, 2024
    '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
    jcfr pushed a commit to python-cmake-buildsystem/python-cmake-buildsystem that referenced this issue Aug 24, 2024
    '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
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    release-blocker type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests