Introduction

If you need to detect the Python version at runtime, the standard answer is to use the sys module, especially sys.version_info. It gives you structured version components that are easy to compare in code. In most cases, that is better than parsing version strings manually.

Use sys.version_info for comparisons

The most reliable runtime check is sys.version_info:

1import sys
2
3print(sys.version_info)
4print(sys.version_info.major)
5print(sys.version_info.minor)
6print(sys.version_info.micro)

You can compare it directly as a tuple-like value:

1import sys
2
3if sys.version_info >= (3, 10):
4    print("Python 3.10 or newer")
5else:
6    print("Older than Python 3.10")

This is the normal way to gate behavior based on interpreter version.

sys.version is informative, but not ideal for logic

Python also exposes sys.version:

import sys

print(sys.version)

That gives a human-readable string containing the version plus build details. It is useful for logging and diagnostics, but it is not the best choice for conditionals because string parsing is more fragile than using version_info.

A good rule is:

• use sys.version_info for program logic
• use sys.version for display or debugging

The platform module is fine for presentation

If you want a formatted version string, the platform module can help:

1import platform
2
3print(platform.python_version())
4print(platform.python_version_tuple())

This is convenient when printing environment information, but for feature checks sys.version_info is still the better API.

Use version checks sparingly

Version checks are sometimes necessary, but often the better pattern is feature detection. For example, if you only care whether a module or attribute exists, it may be cleaner to test that directly rather than hard-coding a version threshold.

Example:

1try:
2    from importlib import resources
3except ImportError:
4    import importlib_resources as resources

That kind of code is often more robust than saying "if Python is at least version X, do Y." It focuses on the capability your program actually needs.

Still, version checks are appropriate when the language syntax or standard-library contract genuinely changed across releases.

Write comparisons clearly

Avoid awkward string comparisons like this:

1import sys
2
3# Do not do this
4if sys.version < "3.10":
5    print("old")

That is not reliable because string ordering does not match semantic version ordering in all cases.

Prefer this:

1import sys
2
3if sys.version_info < (3, 10):
4    print("old")

That expresses the intent correctly and avoids subtle comparison bugs.

Runtime checks do not replace environment testing

Version detection is useful inside application logic, but it should not be your only compatibility strategy. If your project claims to support several interpreter versions, test those environments in CI and packaging workflows too. A runtime guard can prevent one code path from crashing, but it does not prove that the full dependency set behaves correctly on every version you support.

Common Pitfalls

The most common mistake is parsing sys.version as a string when sys.version_info already provides structured fields for correct comparison.

Another common issue is comparing version strings lexicographically, which can produce wrong results.

People also overuse version checks when feature detection would be more robust. If the code only needs a capability, test for that capability directly when possible.

Finally, remember that runtime version detection does not replace testing. If a library or syntax feature matters, validate the code on the interpreter versions you claim to support.

Summary

• Use sys.version_info for runtime Python version checks.
• Use sys.version or platform.python_version() for display and diagnostics.
• Compare versions as tuples, not as raw strings.
• Prefer feature detection over version detection when capability is the real requirement.
• Keep version checks focused on real compatibility boundaries.