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

platform: get macOS version rather than darwin version #79525

Closed
vstinner opened this issue Nov 28, 2018 · 8 comments
Closed

platform: get macOS version rather than darwin version #79525

vstinner opened this issue Nov 28, 2018 · 8 comments
Labels
3.8 (EOL) end of life OS-mac stdlib Python modules in the Lib dir

Comments

@vstinner
Copy link
Member

BPO 35344
Nosy @ronaldoussoren, @vstinner, @ned-deily
PRs
  • bpo-35344: platform.platform() uses mac_ver() on macOS #10780
  • 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 2018-12-05.21:58:27.529>
    created_at = <Date 2018-11-28.22:55:01.886>
    labels = ['OS-mac', '3.8', 'library']
    title = 'platform: get macOS version rather than darwin version'
    updated_at = <Date 2018-12-05.21:58:27.528>
    user = 'https://github.com/vstinner'

    bugs.python.org fields:

    activity = <Date 2018-12-05.21:58:27.528>
    actor = 'vstinner'
    assignee = 'none'
    closed = True
    closed_date = <Date 2018-12-05.21:58:27.529>
    closer = 'vstinner'
    components = ['Library (Lib)', 'macOS']
    creation = <Date 2018-11-28.22:55:01.886>
    creator = 'vstinner'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 35344
    keywords = ['patch']
    message_count = 8.0
    messages = ['330636', '330637', '330641', '330644', '330647', '330658', '330659', '331176']
    nosy_count = 3.0
    nosy_names = ['ronaldoussoren', 'vstinner', 'ned.deily']
    pr_nums = ['10780']
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue35344'
    versions = ['Python 3.8']

    @vstinner
    Copy link
    Member Author

    Would it be possible to get the macOS version (platform.mac_ver()) rather than the darwin version (uname()) for platform.platform()? As an user, I prefer the OS (macOS) version rather than the kernel (darwin) version.

    Current output

    $ ./python.exe -m platform
    Darwin-17.7.0-x86_64-i386-64bit

    versus

    $ ./python.exe -c 'import platform; print(platform.mac_ver())'
    ('10.13.6', ('', '', ''), 'x86_64')

    I tested on:

    $ uname -a
    Darwin macbook 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
    
    $ sw_vers
    ProductName:	Mac OS X
    ProductVersion:	10.13.6
    BuildVersion:	17G65

    @vstinner vstinner added 3.8 (EOL) end of life stdlib Python modules in the Lib dir OS-mac labels Nov 28, 2018
    @vstinner
    Copy link
    Member Author

    It seems like platform.mac_ver() can return None if plistlist is not available. platform.platform() can maybe try mac_ver(), but fallback on uname() if it's not available/working?

    --

    It seems like getting the macOS version without plistlib is not easy:
    https://stackoverflow.com/questions/11072804/how-do-i-determine-the-os-version-at-runtime-in-os-x-or-ios-without-using-gesta

    @ronaldoussoren
    Copy link
    Contributor

    Why do you want to change this?

    The current behavior is consistent with the platform name (Darwin). I’ve filed an issue in the past to change the platform name to “macosx”, but there were good arguments to not change the behavior at the time. The existence of iOS might change that though.

    W.r.t. failing when the Plist is not present: that is unlikely to happen because this is a system file that is hard to remove and is AFAIK documented to exist.

    If the platform version info gets changed, the platform name should change as well.

    Ps. Sorry about the lack of references, I’m away from my computer.

    @vstinner
    Copy link
    Member Author

    Why do you want to change this?

    I created this issue after I read this comment:

    https://bugs.python.org/issue35316#msg330633
    I will investigate with MacOS Mojave this week.

    "Mojave" seems to be the new thing, but I don't recall if my macbook is running it or not. So I checked "python3 -m platform" but it gives me... the darwin version. How am I supposed to guess the macOS version from this output?

    As an user, I see/use "High Sierra" name, or sometimes "macOS 10.12", but I never see/use darwin versions.

    Even inside Python, we rely on the macOS version, not the on the darwin version. For example, @requires_mac_ver of test.support rely on the *macOS* version.

    Example from test_math:

        # log2() is not accurate enough on Mac OS X Tiger (10.4)
        @support.requires_mac_ver(10, 5)
        def testLog2Exact(self):
            ...

    The current behavior is consistent with the platform name (Darwin). I’ve filed an issue in the past to change the platform name to “macosx”, but there were good arguments to not change the behavior at the time.

    I don't expect that any library rely on platform.platform() to detect a platform, so I don't see any risk of backward incompatibility, whereas changing sys.platform would just break every single Python library for what? I don't see any benefit of replacing "darwin" with "macos" or "macosx".

    By the way, we use "win32" for sys.platform, whereas all Windows are now 64-bit...

    W.r.t. failing when the Plist is not present: that is unlikely to happen because this is a system file that is hard to remove and is AFAIK documented to exist.

    I was talking about the plistlib module, not the file on the disk. I am talking about these lines from platform.py:

    try:
        import plistlib
    except ImportError:
        return None
    

    The import can fail for various reasons: module not provided by the Python implementation, missing depending (ex: "from xml.parsers.expat import ParserCreate" in plistlib.py causing an import error), etc.

    I'm not saying that it should be common on CPython, just that it might happen in some weird cases :-)

    @vstinner
    Copy link
    Member Author

    I’ve filed an issue in the past to change the platform name to “macosx”, but there were good arguments to not change the behavior at the time. The existence of iOS might change that though.

    I'm not sure that we are talking about the same thing. I'm talking about sys.platform. Are you talking about platform.system()?

    We might change platform.system(), but that change might be backward incompatible and I'm not sure that it's worth it.

    --

    Why only changing platform.platform()? See the doc:

    .. function:: platform(aliased=0, terse=0)

    Returns a single string identifying the underlying platform with as much useful
    information as possible.

    The output is intended to be *human readable* rather than machine parseable. It
    may look different on different platforms and this is intended.

    (...)

    This string is for humans, and it is not machine parseable. So there is no risk of backward incompatibility.

    @ronaldoussoren
    Copy link
    Contributor

    I should have been clearer in my previous post. I’m not against changing this, but would like an implementation that returns consistent information: either return “macOS” and the macOS version, or “Darwin” and the kernel version.

    IIRC there is, or used to be, a similar issue on Linux where the regular API does not return distribution information. I cannot check the details at the moment.

    Btw. macOS Mojave is the latest macOS release, 10.14, released in September or October.

    @vstinner
    Copy link
    Member Author

    I’m not against changing this, but would like an implementation that returns consistent information: either return “macOS” and the macOS version, or “Darwin” and the kernel version.

    See my PR 10780. It returns "macOS-10.13.6-x86_64" (macOS + macOS version) if mac_ver() works, or "Darwin-17.7.0-x86_64" otherwise (Darwin + darwin version).

    Btw. macOS Mojave is the latest macOS release, 10.14, released in September or October.

    "sw_vers" and platform.mac_ver() confirmed what I guessed: I didn't upgrade yet :-)

    @vstinner
    Copy link
    Member Author

    vstinner commented Dec 5, 2018

    New changeset ea0ca21 by Victor Stinner in branch 'master':
    bpo-35344: platform.platform() uses mac_ver() on macOS (GH-10780)
    ea0ca21

    @vstinner vstinner closed this as completed Dec 5, 2018
    @vstinner vstinner changed the title platform: get macOS version rather than darwin version? platform: get macOS version rather than darwin version Dec 5, 2018
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.8 (EOL) end of life OS-mac stdlib Python modules in the Lib dir
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants