platform: get macOS version rather than darwin version #79525
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
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'
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']
The text was updated successfully, but these errors were encountered:
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.
$ ./python.exe -m platform Darwin-17.7.0-x86_64-i386-64bit
$ ./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
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:
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.
I created this issue after I read this comment:
"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): ...
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...
I was talking about the plistlib module, not the file on the disk. I am talking about these lines from platform.py:
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 :-)
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
The output is intended to be *human readable* rather than machine parseable. It
This string is for humans, and it is not machine parseable. So there is no risk of backward incompatibility.
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.
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).
"sw_vers" and platform.mac_ver() confirmed what I guessed: I didn't upgrade yet :-)