This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients ned.deily, ronaldoussoren, vstinner
Date 2018-11-29.00:34:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1543451673.85.0.788709270274.issue35344@psf.upfronthosting.co.za>
In-reply-to
Content
> 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 :-)
History
Date User Action Args
2018-11-29 00:34:33vstinnersetrecipients: + vstinner, ronaldoussoren, ned.deily
2018-11-29 00:34:33vstinnersetmessageid: <1543451673.85.0.788709270274.issue35344@psf.upfronthosting.co.za>
2018-11-29 00:34:33vstinnerlinkissue35344 messages
2018-11-29 00:34:33vstinnercreate