Repository navigation
platform: get macOS version rather than darwin version #79525
Description
| BPO | 35344 |
|---|---|
| Nosy | @ronaldoussoren, @vstinner, @ned-deily |
| PRs |
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']
Activity
vstinner commentedon Nov 28, 2018
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
versus
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: 17G65vstinner commentedon Nov 28, 2018
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 commentedon Nov 29, 2018
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 commentedon Nov 29, 2018
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:
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 :-)
vstinner commentedon Nov 29, 2018
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 commentedon Nov 29, 2018
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 commentedon Nov 29, 2018
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 :-)
vstinner commentedon Dec 5, 2018
New changeset ea0ca21 by Victor Stinner in branch 'master':
bpo-35344: platform.platform() uses mac_ver() on macOS (GH-10780)
ea0ca21
[-]platform: get macOS version rather than darwin version?[/-][+]platform: get macOS version rather than darwin version[/+]