Repository navigation
platform.system() should be "macosx" instead of "Darwin" on OSX #52098
Description
| BPO | 7850 |
|---|---|
| Nosy | @malemburg, @ronaldoussoren, @jaraco, @vstinner, @jackdied, @JustinCappos, @nchammas |
| Files |
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 2019-02-11.15:04:59.506>
created_at = <Date 2010-02-03.22:40:10.224>
labels = ['type-bug', 'library']
title = 'platform.system() should be "macosx" instead of "Darwin" on OSX'
updated_at = <Date 2019-02-11.15:04:59.506>
user = 'https://github.com/ronaldoussoren'bugs.python.org fields:
activity = <Date 2019-02-11.15:04:59.506>
actor = 'ronaldoussoren'
assignee = 'none'
closed = True
closed_date = <Date 2019-02-11.15:04:59.506>
closer = 'ronaldoussoren'
components = ['Library (Lib)']
creation = <Date 2010-02-03.22:40:10.224>
creator = 'ronaldoussoren'
dependencies = []
files = ['34891']
hgrepos = []
issue_num = 7850
keywords = ['patch']
message_count = 12.0
messages = ['98801', '99790', '99854', '99860', '216370', '217885', '217910', '217911', '259272', '335218', '335219', '335228']
nosy_count = 9.0
nosy_names = ['lemburg', 'ronaldoussoren', 'jaraco', 'vstinner', 'jackdied', 'Justin.Cappos', 'Christian.Clauss', 'math_foo', 'nchammas']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue7850'
versions = ['Python 3.2']
Activity
ronaldoussoren commentedon Feb 3, 2010
The output of platform.system() should IMO be "macosx" on OSX to ensure that platform.platform() is consistent with distutils.util.get_platform().
The same is true for sys.platform, although it is unclear how much code that would break.
There are two reasons for wanting these changes. First of all the values tend to end up at locations where less sophistated users might see them unless we're careful (tests for 'sys.platform' in scripts, platform names in distributions, ...) and 'darwin' is not obviously related to MacOSX unless you're already quite technical. The other reason is slightly nit picking: "Darwin" is the name of the kernel and a stand-alone unix based on that, which MacOSX is the name of the entire system which includes much more beyond basic unix stuff.
BTW. I know why sys.platform is "darwin" on OSX, that doesn't mean I have to like it ;-)
jackdied commentedon Feb 22, 2010
-1, my Ubuntu laptop says "linux2" and not "ubuntu." This would also be an incompatible change that would cause headaches with little benefit to balance it out.
justincappos commentedon Feb 22, 2010
Perhaps the right way to fix the problem without breaking code would be to propose a new function for platform which would return a 'newbie readable' string of the system type?
malemburg commentedon Feb 22, 2010
platform.system() is a direct interface to platform.uname() which in return is an interface to the platform's uname() API, so the reasoning is much the same as for sys.platform on those platforms that do expose a uname() function (and command).
On Mac OS X, uname returns "Darwin".
What we can do, is add a new function parameter ''aliased'' (just like we have for platform.platform()) which then enables applying some aliasing to the returned uname() values.
mathfoo commentedon Apr 15, 2014
Added aliased option to platform.system(). I used the same system_alias method as platform.platform(), so the result of the aliased version will match the system entry of the aliased platform.platform().
Added to platform.system unit test to test new functionality. Updated Documentation.
I am not sure if there is anywhere else I need to update the documentation to add this, i.e. if it needs a whatsnews entry (and if so, a pointer to docs on how to add to a whatsnews entry would be appreciated).
ChristianClauss commentedon May 4, 2014
assert sys.platform == platform.system().lower()
Should that always be True? It is on Mac OS X but...
On iOS (Pythonista):
sys.platform ==> 'unknown'
platform.system() ==> 'Darwin'
https://docs.python.org/2/library/sys.html#sys.platform should be updated to provide the correct values for iOS and Android devices which now outnumber many of the other OSes listed.
malemburg commentedon May 5, 2014
Caelyn: Thanks for the patch.
Some comments:
malemburg commentedon May 5, 2014
Removing 2.7 as target, since this is a new feature.
nchammas commentedon Jan 31, 2016
As of Python 3.5.1 [0], it looks like
the
aliasedandterseparameters ofplatform.platform()are documented to take integers instead of booleans (contrary to what Marc-Andre requested), andcalling
platform.platform()withaliasedset to 1 or True still returns "Darwin" on OS X.Is this by design?
[0] https://docs.python.org/3.5/library/platform.html#platform.platform
jaraco commentedon Feb 11, 2019
This issue now needs to consider that Mac OS X was renamed to macOS.
vstinner commentedon Feb 11, 2019
I suggest to close this issue.
@ronald: Or do you think that something should still be done on macOS in the platform module?
This issue looks like a duplicate of bpo-35516. It has been decided that platform.system_alias() doesn't replace Darwin with macOS (it's now explained in a comment: see my commit 60875db).
I modified platform.platform() to return "macOS" rather than "darwin" on macOS: "bpo-35344: platform.platform() uses mac_ver() on macOS (GH-10780)" (commit ea0ca21).
ronaldoussoren commentedon Feb 11, 2019
This issue can be closed. Status quo wins due to backward compatibility concerns.
BTW. The primary reason for proposing "macosx" as the return value for platform.system() is that the platform name as used in egg files (at the time, now wheels) is "macosx". That, and having two clearly different platforms with the same name (macOS and iOS).
And one final note: I definitely wouldn't mind having an API in platform that returns the marketing name and version of the current system (like mac_ver and linux_distribution). But that API cannot be system_alias because its API contract does not give it access to enough information. Such an API could be designed in a new issue.