Introduction

The only reliable way to know which Python version is running your script is to ask the interpreter from inside the process. Shell commands such as python --version are useful diagnostics, but they tell you what the shell resolves, not necessarily what your current process is executing.

Read the Version from sys

The standard library already exposes everything you need through the sys module.

1import sys
2
3print("sys.version:", sys.version)
4print("sys.version_info:", sys.version_info)
5print("major.minor:", f"{sys.version_info.major}.{sys.version_info.minor}")

sys.version is a human-readable string that includes extra build details. sys.version_info is a structured tuple-like value that is better for comparisons in code.

If you only need to show the version in logs or support output, sys.version.split()[0] is often enough. If you need logic, use sys.version_info.

Add a Version Guard for Minimum Requirements

Many scripts depend on features that only exist in newer Python releases. A version guard lets the script fail early with a clear error instead of crashing later with confusing syntax or import problems.

1import sys
2
3REQUIRED = (3, 10)
4
5if sys.version_info < REQUIRED:
6    raise RuntimeError(
7        f"Python {REQUIRED[0]}.{REQUIRED[1]} or newer is required, "
8        f"but this process is running {sys.version_info.major}.{sys.version_info.minor}"
9    )
10
11print("Version requirement satisfied")

This is much easier to diagnose than discovering halfway through execution that a needed feature is missing.

Print the Interpreter Path Too

When multiple Python installations exist on the same machine, the version alone may not be enough. The executable path tells you which interpreter binary launched the current process.

import sys

print("Executable:", sys.executable)

That helps answer questions such as:

• is the script using system Python or a virtual environment
• did pyenv, conda, or Docker select a different interpreter than expected
• are tests running under the same Python that installed the dependencies

For command-line tools, a small runtime banner can be useful:

1import os
2import sys
3
4
5def print_runtime_info() -> None:
6    print("Python:", sys.version.split()[0])
7    print("Executable:", sys.executable)
8    print("Virtual environment:", os.environ.get("VIRTUAL_ENV", "not set"))
9
10
11if __name__ == "__main__":
12    print_runtime_info()

Compare Shell Checks with Runtime Checks

Shell commands still have value, especially when debugging environment setup:

1python --version
2python3 --version
3which python
4which python3

But treat those as supporting clues. If your script says it is running under Python 3.11, that is the source of truth for the actual process.

Common Pitfalls

The most common mistake is parsing sys.version as a raw string for comparisons. String comparisons are fragile and unnecessary. Use sys.version_info instead.

Another common issue is trusting python --version from the terminal while the script is actually launched by a virtual environment, IDE, service manager, or container using a different interpreter.

People also forget to record the executable path when debugging deployment issues. Two interpreters can have the same major version but different package environments, which changes behavior just as much as a version mismatch.

Finally, if your package only supports newer Python versions, declare that requirement in packaging metadata as well. Runtime checks help users, but build metadata helps tooling.

It is also worth logging the runtime version in scheduled jobs or long-lived services. When an environment is upgraded underneath you, that one line can save a lot of debugging time.

Summary

• Use sys.version to display the running Python version.
• Use sys.version_info for reliable version comparisons in code.
• Print sys.executable when interpreter selection may be ambiguous.
• Treat shell commands as diagnostics, not as the source of truth for a running process.
• Add clear version guards when your script requires a minimum Python release.