How to Check Your Python Version (and Which Python You’re Actually Running)

• 27 June 2026
• by: Ravi Subramanian
• in: Web hosting
• Tags: check python version, Python, python version
• note: no comments

You typed `python –version`, got a number, and moved on. Most of the time that’s fine. But the moment a project breaks with “this feature requires Python 3.10+” while you’re *sure* you have 3.12 installed, you’ve hit the real lesson hiding inside this simple question: a machine usually has more than one Python, and the one you just checked may not be the one running your code.

This guide covers every way to check your Python version — from the command line, from inside the interpreter, and across the multiple Pythons that live on a typical developer machine. It’s part of our complete guide to a real development environment you control, and it’s written for people who want the version number *and* the context behind it.

Key Takeaways
• Run `python –version`, `python -V`, or `python3 –version` to check from the shell. They all print the same thing for a given interpreter.
• `python` and `python3` can point to different interpreters — this is the single most common source of Python version confusion.
• Inside Python, use `import sys; sys.version_info` for version logic and `platform.python_version()` for a clean string.
• Always pair the version with location: `python –version` *plus* `which python` (or `where python` on Windows).
• Use virtual environments per project so each project pins its own interpreter and “the version” becomes unambiguous.

What is the fastest way to check the Python version from the command line?

Three commands. They’re equivalent and you’ll see all of them in documentation:

“`bash python –version python -V python3 –version “`

Typical output:

“`text Python 3.12.4 “`

Note the capital `V` in `-V` — lowercase `-v` triggers verbose mode, which dumps a wall of import logging instead of a version string. The long form `–version` is the one to memorize.

The platform commands are nearly identical:

“`bash

python –version py –version # the Python launcher, Windows-specific

python3 –version python3 -V “`

On Windows, the `py` launcher deserves a special mention. It ships with the official python.org installer and is the recommended way to invoke Python on Windows because it resolves the right interpreter for you:

“`text C:\> py –version Python 3.12.4

C:\> py -3.11 –version Python 3.11.9 “`

That `-3.11` flag is your first hint that multiple versions coexist routinely — we’ll get to that.

Why do `python` and `python3` show different versions?

This is the trap that sends developers in circles. `python` and `python3` are just names that point at executables, and nothing forces them to point at the same one.

The history: Python 2 and Python 3 were incompatible, and for years Linux systems shipped `python` meaning “Python 2” and `python3` meaning “Python 3” to avoid breaking system scripts. Even now that Python 2 is dead, the naming inertia remains, and on a fresh machine you might find:

“`bash $ python –version Python 2.7.18 # legacy, or “command not found” on newer systems

$ python3 –version Python 3.12.4 # the one you actually want “`

Or the reverse, once you install something that creates a `python` alias. The takeaway is simple but load-bearing: the version you get depends on the name you typed. Don’t assume `python` means your latest install.

Here’s the reframe that ends the confusion for good. The deceptively simple question “what’s my Python version?” has no single answer on a real machine, because a typical developer box has several Pythons: the system Python, one or more from python.org or your package manager, versions managed by pyenv, and a fresh isolated copy inside every virtual environment. The `python` command, `python3`, the interpreter your IDE selected, and the Python that `pip` installs into can all be *different binaries*. So stop asking “what version is Python.” Ask instead: “which python am I running, and what version is THAT?” The pro habit is to never check a version alone — always check version *and location together*, and scope each project to its own virtual environment so the answer is unambiguous by construction.

How do you check which Python interpreter you’re actually using?

Pair the version with its path. This one step resolves the vast majority of “wrong version” mysteries.

“`bash

which python which python3

where python

Get-Command python | Select-Object Source “`

Now combine them into a single mental command — version *and* location:

“`bash python –version && which python “`

“`text Python 3.12.4 /Users/ravi/projects/api/.venv/bin/python “`

That second line tells you something the version alone never could: you’re running the interpreter inside a project’s `.venv`, not the system one. When a colleague says “works on my machine,” this is almost always where the difference lives.

How do you check the Python version from inside a script?

Sometimes you need the version programmatically — to guard a feature, log an environment, or fail fast. Python exposes this through the `sys` and `platform` modules.

“`python import sys

print(sys.version)

print(sys.version_info)

print(sys.version_info.major) # 3 print(sys.version_info.minor) # 12 “`

For version *checks* in code, compare the tuple — never parse the string:

“`python import sys

if sys.version_info < (3, 10): raise RuntimeError("This project requires Python 3.10 or newer.") ```

When you want a clean `”3.12.4″` with no build noise, reach for `platform`:

“`python import platform

print(platform.python_version()) # 3.12.4 print(platform.python_version_tuple()) # (‘3′, ’12’, ‘4’) print(platform.python_implementation()) # CPython (or PyPy, Jython…) “`

Use `sys.version_info` for branching logic and `platform.python_version()` for display and logging. Both read from the *running* interpreter, so they’re the ground truth for “what’s actually executing this code.”

Which command shows what? A quick reference

Command	Where you run it	What it shows
`python –version` / `python -V`	Shell	Version of the `python` on your PATH
`python3 –version`	Shell	Version of the `python3` on your PATH
`py –version` (Windows)	Shell	Version the Windows launcher resolves to
`which python` / `where python`	Shell	File path of the interpreter being used
`pip –version`	Shell	pip version and the Python it installs into
`import sys; sys.version_info`	Inside Python	Comparable version tuple of the running interpreter
`platform.python_version()`	Inside Python	Clean `major.minor.patch` string

How do you check which Python pip installs into?

`pip` is itself a Python program, and each Python install has (or should have) its own `pip`. If you `pip install requests` and your script still raises `ModuleNotFoundError`, you almost certainly installed into a *different* Python than the one running your code.

`pip –version` is unusually helpful here because it prints the associated interpreter:

“`bash $ pip –version pip 24.0 from /Users/ravi/projects/api/.venv/lib/python3.12/site-packages/pip (python 3.12) “`

Read the tail: `(python 3.12)` and the path tell you exactly which Python this pip serves. The bulletproof pattern is to invoke pip *through* a specific interpreter, which removes all ambiguity:

“`bash python -m pip –version python3 -m pip install requests py -3.11 -m pip install requests # Windows, target 3.11 explicitly “`

`python -m pip` guarantees the package lands in the *same* Python you’d run with `python`. Make this your default and a whole category of “I installed it but it’s not found” bugs disappears.

How do you handle multiple Python versions on one machine?

Real projects pin real versions. One service needs 3.11, another targets 3.12, a legacy job is stuck on 3.9. You don’t fight this — you manage it.

Named binaries. Most installs expose minor-version-specific executables side by side:

“`bash python3.9 –version # Python 3.9.18 python3.11 –version # Python 3.11.9 python3.12 –version # Python 3.12.4 “`

pyenv lets you install and switch between versions cleanly, including a per-directory default:

“`bash pyenv versions # list everything installed pyenv install 3.12.4 # add a version pyenv global 3.12.4 # set the machine default pyenv local 3.11.9 # pin THIS folder to 3.11.9 (writes .python-version)

python –version # now reflects the pyenv-resolved interpreter “`

Virtual environments are the real answer to “which version” — each one is an isolated copy tied to a specific interpreter:

“`bash

python3.11 -m venv .venv

source .venv/bin/activate # macOS / Linux .venv\Scripts\activate # Windows

python –version # Python 3.11.9 which python # …/.venv/bin/python “`

This is why versions matter *per project*: dependencies, syntax features, and behavior shift between releases. A venv pins the interpreter so your project’s “Python version” is no longer a machine-wide guessing game — it’s a property of the project itself. (See the sibling guides below on running Python and managing packages with pip for the full workflow.)

How do you update or install a new Python version?

First, the most important rule on Linux: do not replace the system Python. Tools like `apt`, `dnf`, and parts of your OS depend on the exact version shipped. Overwriting it can brick package management. Instead, install *additional* versions alongside it.

Via package manager (installs a new version next to the system one):

“`bash

brew install [email protected]

sudo add-apt-repository ppa:deadsnakes/ppa sudo apt update sudo apt install python3.12

sudo dnf install python3.12 “`

Via pyenv (cleanest for juggling many versions, never touches system Python):

“`bash pyenv install 3.12.4 pyenv global 3.12.4 “`

Via python.org — download the official installer for Windows or macOS. On Windows, check “Add Python to PATH” during install, then use the `py` launcher to pick versions. python.org is also the authoritative place to see the latest Python new version releases and their support timelines.

After any install, verify with the version-and-location habit:

“`bash python3.12 –version && which python3.12 “`

How do you read a Python version number?

Python uses `major.minor.patch` (semantic-style versioning):

“`text Python 3.12.4 │ │ │ │ │ └── patch (micro): bug fixes only, fully compatible │ └───── minor: new features, new syntax, usually backward compatible └──────── major: rare, can break compatibility (the 2 → 3 jump) “`

What this means in practice:

• Patch (`3.12.4` → `3.12.5`): safe to update, security and bug fixes, no code changes needed.
• Minor (`3.11` → `3.12`): new capabilities; mostly compatible but worth testing. This is the number most “requires Python 3.X+” constraints care about.
• Major (`2` → `3`): a generational break. There’s no `4` on the horizon, so for now `3` is simply “Python.”

For dependency rules, the minor version is almost always what matters — which is exactly why `sys.version_info[:2]` (the `(major, minor)` slice) is the value you check most often in real code.

Frequently asked questions

Why does `python –version` say “command not found”? On many modern systems only `python3` is installed; there’s no bare `python`. Use `python3 –version`, or create an alias. On Windows, the `python` command may be a Microsoft Store stub — install from python.org and use `py` instead.

Is `python -V` the same as `python –version`? Yes, identical output. Just remember it’s a capital `V`; lowercase `-v` is verbose import mode and prints something completely different.

My IDE shows a different version than my terminal. Why? Your IDE has its own configured interpreter (often a project’s virtual environment), while your terminal uses whatever is on your shell’s PATH. They’re two different Pythons. Point your IDE at the same `.venv` your terminal uses, and they’ll agree.

How do I check the version without opening a terminal at all? Run a one-liner: `python -c “import sys; print(sys.version)”`. It launches the interpreter, prints the version, and exits — handy inside scripts, CI logs, and Dockerfiles.

Should I always use the newest Python version? For new projects, the current stable release is a good default. But pin each project to a specific version with a virtual environment, and only upgrade after testing — minor releases occasionally change behavior your dependencies rely on.

---

The bottom line: checking your Python version is a two-part question, not one. The number from `python –version` only means something once you know *which* interpreter produced it. Pair every version check with a location check, scope each project to its own virtual environment, and “what version is Python” stops being a mystery — because you’ll always know exactly which Python you’re asking about.