How do sys.platform, os.name and platform.system() differ, and when do you use each?

### Three questions that look like one "Which operating system am I on?" is actually three different questions in Python, and the standard library answers each with a different object. **`sys.platform` — a build-time constant.** Its value is decided when CPython itself is compiled and never changes for the life of that interpreter. On Linux it is exactly `'linux'` (Python 2 builds said `'linux2'`, which is the historical reason the documentation recommends a prefix test). On macOS it is `'darwin'`. On Windows it is `'win32'` — on 64-bit installations too, because the string names the Win32 API family, not a pointer width. Other values you may meet include `'cygwin'`, `'wasi'`, `'emscripten'`, and, since Python 3.13 made those platforms supported, `'ios'` and `'android'`. On some systems the value carries a major version suffix (FreeBSD builds report `'freebsd13'`, `'freebsd14'`), which is why the documented form of the test is `sys.platform.startswith('freebsd')` — and by the same habit `sys.platform.startswith('linux')`. Being a constant has a second, underrated payoff: a static type checker understands a branch guarded by `sys.platform == 'win32'` and treats the other branch as unreachable on that platform, so platform-only standard-library attributes inside it stop being reported as errors. A runtime function call gives you none of that narrowing. **`os.name` — which syscall family.** It names the low-level OS-dependent module that `os` re-exports, and on today's CPython it is `'posix'` or `'nt'`. It answers "are POSIX-style calls available here", not "which OS is this": Linux, macOS, the BSDs, Cygwin and WSL all report `'posix'`, so a program that branches on `os.name` to special-case macOS is simply broken. Use it when the question really is API availability — whether `os.fork` exists, whether `os.symlink` behaves the way you assume — and prefer an explicit `hasattr(os, 'fork')` when you can, because that is the property you actually care about. **`platform.system()` — a runtime query.** It asks the running system rather than reading a constant; on POSIX it is essentially the `sysname` field you also get from `os.uname()`, and on Windows it is `'Windows'`. Its strings are capitalized and spelled differently from `sys.platform`'s: `'Linux'`, `'Darwin'`, `'Windows'`. Two details interviewers probe. First, the documentation states it returns an **empty string** when the value cannot be determined, so any dictionary dispatch keyed on it needs a fallback. Second, because it is a call rather than a literal comparison, no type checker narrows on it and it is marginally more expensive. ### How to choose The ordering that survives review is: **feature detection first, `sys.platform` second, `platform` for reporting.** If the real question is "can I call this", test for the capability. If you genuinely need a platform branch — a different default directory, a different signal strategy — branch on `sys.platform` with `startswith`, because it is cheap, constant, and analyzable. Reserve the `platform` module for things you display or log: `platform.system()`, `platform.release()`, `platform.machine()`, `platform.uname()`. Architecture is a **separate axis** and a common blind spot: `sys.platform` is `'darwin'` on both Apple-silicon and Intel Macs, and `'linux'` on both x86-64 and ARM servers. `platform.machine()` is what distinguishes them, returning values like `'x86_64'`, `'arm64'` or `'AMD64'`. For the platform tag that describes compiled artefacts, `sysconfig.get_platform()` is the right source. Linux distribution identity is yet another axis. The old distro-name helper was removed from the `platform` module in Python 3.8; the modern replacement is `platform.freedesktop_os_release()`, added in 3.10, which parses the standard os-release file and raises `OSError` when no such file can be read. ### Where each one actually shows up In a real codebase the three cluster in different places. `sys.platform` appears in library code: the branch that picks a default temporary directory, the one that decides whether to install a signal handler, the one that selects between two implementations of the same helper. `os.name` appears in a much smaller number of places, guarding calls that simply do not exist on the other family, and it is often better replaced by `hasattr` on the specific attribute, because that is a narrower and more honest claim than "this is a POSIX system". The `platform` module concentrates in exactly two places: the `--version` output or diagnostic banner your program prints, and the crash or telemetry report it sends when something goes wrong. If you find `platform.system()` deciding control flow deep inside a hot function, that is usually a `sys.platform` comparison written by someone who reached for the module with the friendlier name. ### Traps Do not branch on the platform to build file paths. `os.path` and `pathlib` already encode the differences, and `os.sep`, `os.altsep`, `os.pathsep` and `os.linesep` expose them directly when you need the raw characters. Container and WSL environments report `'linux'` and `'posix'` exactly like bare metal, which is usually what you want and occasionally exactly what confuses you. And in tests, remember that patching the attribute — `unittest.mock.patch('sys.platform', 'win32')` — only changes what code reads *afterwards*; any module that already made its decision at import time keeps it, so import-time platform branches are effectively untestable in-process, which is itself an argument for keeping the branch inside a function.