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:
https://stackoverflow.com/questions/11072804/how-do-i-determine-the-os-version-at-runtime-in-os-x-or-ios-without-using-gesta

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.

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

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

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.

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

New changeset ea0ca218b0c28b2af2b1f6a5d3383569de7fc2c1 by Victor Stinner in branch 'master':
bpo-35344: platform.platform() uses mac_ver() on macOS (GH-10780)
https://github.com/python/cpython/commit/ea0ca218b0c28b2af2b1f6a5d3383569de7fc2c1