-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
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
Comments
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 |
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 :-) |
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: