141

As far as I know, Python has 3 ways of finding out what operating system is running on:

  1. os.name
  2. sys.platform
  3. platform.system()

Knowing this information is often useful in conditional imports, or using functionality that differs between platforms (e.g. time.clock() on Windows v.s. time.time() on UNIX).

My question is, why 3 different ways of doing this? When should one way be used and not another? Which way is the 'best' (most future-proof or least likely to accidentally exclude a particular system which your program can actually run on)?

It seems like sys.platform is more specific than os.name, allowing you to distinguish win32 from cygwin (as opposed to just nt), and linux2 from darwin (as opposed to just posix). But if that's so, that what about the difference between sys.platform and platform.system()?

For example, which is better, this:

import sys
if sys.platform == 'linux2':
    # Do Linux-specific stuff

or this? :

import platform
if platform.system() == 'Linux':
    # Do Linux-specific stuff

For now I'll be sticking to sys.platform, so this question isn't particularly urgent, but I would be very grateful for some clarification regarding this.

CharlesB
  • 86,532
  • 28
  • 194
  • 218
ztangent
  • 1,811
  • 2
  • 14
  • 11
  • 20
    use `sys.platform.startswith('linux')` instead of `sys.platform == 'linux2'` for future compatibility – jfs Jul 26 '12 at 14:52
  • I do it this way: if sys.platform == "linux" or sys.platform == "linux2": – Robin Oct 11 '21 at 03:38

6 Answers6

90

Dived a bit into the source code.

The output of sys.platform and os.name are determined at compile time. platform.system() determines the system type at run time.

  • sys.platform is specified as a compiler define during the build configuration.
  • os.name checks whether certain os specific modules are available (e.g. posix, nt, ...)
  • platform.system() actually runs uname and potentially several other functions to determine the system type at run time.

My suggestion:

  • Use os.name to check whether it's a posix-compliant system.
  • Use sys.platform to check whether it's a linux, cygwin, darwin, atheos, etc.
  • Use platform.system() if you don't believe the other sources.
Brand0R
  • 1,413
  • 11
  • 17
moooeeeep
  • 31,622
  • 22
  • 98
  • 187
24

There is a thin line difference between platform.system() and sys.platform and interestingly for most cases platform.system() degenerates to sys.platform

Here is what the Source Python2.7\Lib\Platform.py\system says

def system():

    """ Returns the system/OS name, e.g. 'Linux', 'Windows' or 'Java'.

        An empty string is returned if the value cannot be determined.

    """
    return uname()[0]

def uname():
    # Get some infos from the builtin os.uname API...
    try:
        system,node,release,version,machine = os.uname()
    except AttributeError:
        no_os_uname = 1

    if no_os_uname or not filter(None, (system, node, release, version, machine)):
        # Hmm, no there is either no uname or uname has returned
        #'unknowns'... we'll have to poke around the system then.
        if no_os_uname:
            system = sys.platform
            release = ''
            version = ''
            node = _node()
            machine = ''

Also per the documentation

os.uname()

Return a 5-tuple containing information identifying the current operating system. The tuple contains 5 strings: (sysname, nodename, release, version, machine). Some systems truncate the nodename to 8 characters or to the leading component; a better way to get the hostname is socket.gethostname() or even socket.gethostbyaddr(socket.gethostname()).

Availability: recent flavors of Unix.
Abhijit
  • 62,056
  • 18
  • 131
  • 204
11

From sys.platform docs:

  • os.name has a coarser granularity
  • os.uname() gives system-dependent version information
  • The platform module provides detailed checks for the system’s identity

Often the "best" future-proof way to test whether some functionality is available is just to try to use it and use a fallback if it fails.

what about the difference between sys.platform and platform.system()?

platform.system() returns a normalized value that it might get from several sources: os.uname(), sys.platform, ver command (on Windows).

jfs
  • 399,953
  • 195
  • 994
  • 1,670
10

It depends on whether you prefer raising exception or trying anything on an untested system and whether your code is so high level or so low level that it can or can't work on a similar untested system (e.g. untested Mac - 'posix' or on embedded ARM systems). More pythonic is to not enumerate all known systems but to test possible relevant properties. (e.g. it is considered important the endianess of the system but unimportant multiprocessing properties.)

  • os.name is a sufficient resolution for the correct usage of os module. Possible values are 'posix', 'nt', 'os2', 'ce', 'java' or 'riscos' in Python 2.7, while only the 'posix', 'nt' and 'java' are used since Python 3.4.

  • sys.platform is a finer resolution. It is recommended to use if sys.platform.startswith('linux') idiom because "linux2" means a Linux kernel version 2.xx or 3. Older kernels are currently never used. In Python 3.3 are all Linux systems simple 'linux'.

I do not know the specifics of "Mac" and "Java" systems and so I can not use the results of very good method platform.system() for branching, but I would use advantages of the platform module for messages and error logging.

hynekcer
  • 14,942
  • 6
  • 61
  • 99
  • `os.name` possible return values are `'posix'`, `'nt'`, `'java'` according to [Python 3 docs](https://docs.python.org/3/library/os.html#os.name). See also: [platform module docs](https://docs.python.org/3/library/platform.html). I do _not_ believe `'riscos'` and `'os2`' are possible return values from `os.name`; they may be [return values from `sys.platform`](https://stackoverflow.com/a/13874620/737230). The [Python 3 `sys.platform` documentation](https://docs.python.org/3/library/sys.html#platform) does not appear to be exhaustive. – afeique Jul 24 '18 at 20:27
  • 1
    @afeique: I updated my answer for newer Python, but it was right at that time. See [Python 3.3 - os.name](https://docs.python.org/3.3/library/os.html#os.name) (the latest version at that time). Python 2.7 is still supported and 'riscos' is a possible value for it. – hynekcer Jul 24 '18 at 22:22
  • Thanks @hynekcer, I appreciate your edit to add Python version numbers. I apologize for not realizing it changed after Python 3.3. I did not peruse the different versions of the documentation and made the gross assumption that Python 3 behaviour of `os.name` was consistent across versions. I also did not double-check the [2.7 documentation](https://docs.python.org/2.7/library/os.html#os.name), but I know now that you're correct. – afeique Jul 25 '18 at 13:57
3

I believe the platform module is probably preferred for new code. The others existed before it. It is an evolution, and the others remain for backwards compatibility.

Keith
  • 42,110
  • 11
  • 57
  • 76
  • 10
    I wonder if we can get any Python developers to confirm this. Maybe even whoever developed the platform module. – ztangent Dec 30 '10 at 02:59
0

sys.platform is determined at compile time, platform.system() determines at run time.

This means the former usage has the ability to check syntax and dim unreachable code blocks in IDE.

IMO, if sys.platform can meet your needs and works fine in your code, use it.

yakamoz423
  • 1
  • 2