Possible Values from Sys.Platform

Possible values from sys.platform?

Mac OS X (10.4, 10.5, 10.7, 10.8):

darwin

Linux (2.6 kernel):

linux2

Windows XP 32 bit:

win32

Versions in brackets have been checked - other/newer versions are likely to be the same.

What are the currently possible values for sys.maxsize?

• sys.maxsize is telling you something about the C compiler used to compile CPython, so there's no difference between Python 2 and Python 3. It has to do with the C compiler and options that were used, not with the version of Python being compiled.
• It's the largest positive integer that fits in the platform C compiler's ssize_t type. Which is a 32-bit or 64-bit signed 2's-complement integer on all platforms I've ever seen ;-) Which correspond exactly to the two specific values you already found.
• It's called type Py_ssize_t in the docs because Python had to create its own typedefs (at the C level) for newer C concepts waiting for all the world's C compilers to implement them. Those Python-specific typedefs typically stick around in the source code even after all known C compilers catch up ("not broke, don't fix").

How can I mock the value of sys.platform in python

Hope this is what you are looking for, here is how I was able to mock the platform (running on Mac):

myfunc.py

import sys

# function that I am testing
def print_os():
    if sys.platform == "win32":
        return "We are Windows"
    elif sys.platform == "darwin":
        return "We are Darwin"
    elif sys.platform == "linux":
        return "We are Linux"

myfunc_test.py

import unittest
from unittest.mock import patch

import myfunc

@patch('sys.platform', 'linux')
class TestOS(unittest.TestCase):
    def test_print_os(self):
        self.assertEqual(myfunc.print_os(), "We are Linux")

if __name__ == '__main__':
    unittest.main()

testing:

$ python -m unittest -v myfunc_test.py
test_print_os (main_test.TestOS) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

What values are given for the `os.name` family of functions on various platforms in Python?

Linux:

>>> import os
>>> os.name
'posix'
>>> import platform
>>> platform.system()
'Linux'
>>> import sys
>>> sys.platform
'linux2'

Mac OS:

>>> import os
>>> os.name
'posix'
>>> import platform
>>> platform.system()
'Darwin'
>>> import sys
>>> sys.platform
'darwin'

Windows:

>>> import os
>>> os.name
'nt'
>>> import platform
>>> platform.system()
'Windows'
>>> import sys
>>> sys.platform
'win32'

Cygwin:

>>> import os
>>> os.name
'posix'
>>> import platform
>>> platform.system()
'CYGWIN_NT-10.0'
>>> import sys
>>> sys.platform
'cygwin'

What are the potential results for platform.system()

platform.system() retrieves its information from the uname system call if available, or synthesizes a result if uname is not available. That means that there is no fixed set of possible returns—it gets it directly from the operating system, and the operating system can return whatever it wants there. For what it’s worth, Mac OS X will return Darwin. (If you’re interested, check the source.)

What is platform.system() output for MacOS?

You are using the platform library (platform.system() == 'Darwin'). The post you linked to uses the sys library (sys.platform == 'darwin'). With the library you are using, the string is 'Darwin'. I hope that helps.

Is it safe to use sys.platform=='win32' check on 64-bit Python?

sys.platform will be win32 regardless of the bitness of the underlying Windows system, as you can see in PC/pyconfig.h (from the Python 2.6 source distribution):

#if defined(MS_WIN64)
/* maintain "win32" sys.platform for backward compatibility of Python code,
   the Win64 API should be close enough to the Win32 API to make this
   preferable */
#       define PLATFORM "win32"

It's possible to find the original patch that introduced this on the web, which offers a bit more explanation:

The main question is: is Win64 so much more like Win32 than different from it that the common-case general Python programmer should not ever have to make the differentiation in his Python code. Or, at least, enough so that such differentiation by the Python scriptor is rare enough that some other provided mechanism is sufficient (even preferable). Currently the answer is yes. Hopefully MS will not change this answer.

---

Related Topics