What it is

Python is a high-level, general-purpose programming language created by Guido van Rossum and first released in 1991. High-level means it hides the machine: no memory to allocate, no pointers, no types to declare before you can start. General-purpose means it was not built for one domain, which is why the same language ends up training neural networks, renaming ten thousand files, and serving an API.

The design has a stated bias, and it is unusual for a language to have one this explicit: readability over cleverness, one obvious way to do a thing over several clever ones. That bias is why Python reads almost like pseudocode, and why it became the language people are taught first.

It is also open source, developed in the open by the Python Software Foundation and a large volunteer core team, with a new feature release every October. The current series is 3.14, released in October 2025. There is no vendor, no license tier, and no company whose roadmap decides what happens to it.

If you are here to decide how to learn it and whether a credential is worth buying, that is a separate article: Learn Python: courses and certifications.

How it runs

Python is interpreted, in the sense that matters to you day to day: you write a .py file, run it, and it executes. There is no build step, no compiler to configure, no binary to produce. That single fact explains most of the language's ergonomics - the fast edit-run loop, the interactive shell where you test an idea in four seconds, the fact that a beginner's first program is one line rather than a project skeleton.

Underneath it is a little more interesting. The reference implementation, CPython - the thing you install from python.org - first compiles your source to bytecode, a compact instruction set that is not machine code, then executes that bytecode on a virtual machine. The cached bytecode is what those __pycache__ folders hold. So Python does compile; it just does it silently, on the way in, every time it needs to.

CPython is the reference implementation, not the only one. PyPy runs the same language with a just-in-time compiler and is substantially faster on long-running numeric loops. Other implementations exist for other hosts. Unless someone tells you otherwise, though, "Python" means CPython.

The cost of this design is speed. Interpreted bytecode on a virtual machine is slower than compiled native code, often by a lot, and CPython has historically run only one thread of Python code at a time because of the Global Interpreter Lock (GIL). In practice heavy work is delegated to libraries whose numeric cores are written in C or Rust, so the Python layer is coordinating rather than computing. That workaround has carried the language for thirty years and it is finally being addressed directly: Python 3.14 made the free-threaded build - CPython compiled without the GIL - an officially supported option. It is not yet the default, you have to install it deliberately, and C extensions have to opt in, so treat it as a real direction of travel rather than something to assume in your next project.

Indentation is the syntax

Most languages mark a block of code with braces and treat indentation as decoration for humans. Python inverts that: the indentation is the block structure. A line ending in a colon opens a block, and everything indented under it belongs to that block until the indentation goes back out. There are no braces and no end keyword.

Two consequences follow, and they are the first things a newcomer feels. The good one: every Python program you will ever read is indented consistently, because inconsistent indentation is not a style violation, it is a syntax error. Code from strangers looks like your code. The awkward one: whitespace is now load-bearing, so a stray tab mixed into spaces breaks a program in a way that is invisible on screen. Every editor solves this by converting tabs to spaces; the community standard, four spaces per level, is written down in PEP 8, the style guide almost every Python codebase follows.

The rest of the syntax follows the same instinct. Words where other languages use symbols: and, or, not, in. No semicolons at line ends. No type declarations required. The result is a language that a non-programmer can often read approximately correctly, which is exactly why it dominates in fields where the person writing the code is a scientist or an analyst first and a programmer second.

Typing, and what hints changed

Python is dynamically typed: a variable is just a name bound to an object, and the same name can point at a number now and a list later. Types are real and strictly enforced at runtime - you cannot add a number to a string and get away with it - but nothing is checked before the program runs. The trade is the familiar one. You write less to get started, and a typo in a rarely-taken branch waits until production to introduce itself.

Since 2015 the language has had an answer: type hints. You can annotate a function's parameters and return value, and those annotations are ordinary syntax that the interpreter records and otherwise ignores. Nothing is enforced at runtime. The value comes from tools that read them - type checkers like mypy and Pyright that fail your build on a mismatch, and editors that use them for accurate completion and refactoring.

This is gradual typing, and it is the same bargain TypeScript struck for JavaScript, with one significant difference: Python's hints live in the language itself rather than in a separate dialect that must be compiled away. You can annotate one function in a large untyped codebase and gain something immediately.

The practical guidance is boring and correct. Skip hints while you are learning, since they are noise when the whole program fits on a screen. Add them at the boundaries - function signatures, module interfaces, anything another person calls - as soon as a project is big enough that you cannot hold it in your head. Do not retrofit a whole codebase in one sitting.

What it is actually used for

Python is general-purpose, but its gravity is not evenly distributed. Four areas account for most of the work being done in it:

  • Data and machine learning. This is the centre of gravity. NumPy and pandas for arrays and tabular data, Matplotlib for charts, scikit-learn for classical models, PyTorch for deep learning. The reason is historical and self-reinforcing: the numeric libraries arrived early, researchers published in them, and every subsequent tool targeted the same ecosystem.
  • Automation and scripting. The glue work - renaming files, moving data between two systems, calling three APIs and reconciling the answers, anything that would be a painful shell script. A capable standard library and no build step make Python the shortest distance between a chore and a program.
  • Backend services. Django for applications that want batteries included, FastAPI for typed HTTP APIs, Flask for something small. Python is a normal, credible choice for a web backend, though not usually the one chosen for raw throughput.
  • Teaching. The language of introductory computer science courses and of most people's first program, for all the reasons in the sections above.

Where it fits badly is equally clear. Nothing that needs to run in a browser. Nothing where a tight, predictable memory footprint or startup time is the requirement - a CLI you invoke a thousand times a minute, or firmware. Nothing where the CPU-bound inner loop must be fast and cannot be handed to a library. Those are the cases where you reach for a compiled language, and often the answer is to write that one hot piece in Rust or C and keep calling it from Python.

The ecosystem

Python ships with what its documentation calls a batteries-included standard library: JSON, HTTP, dates, filesystem paths, CSV, SQLite, compression, threading, and a hundred other modules available with an import and no install. A surprising amount of real work never needs a third-party package at all.

Beyond that there is PyPI, the Python Package Index, and pip, the installer that pulls from it. pip install requests is the most common second command a Python programmer learns.

The complication - and it is the one thing that genuinely trips up beginners - is that installing a package puts it somewhere, and by default that somewhere is shared. Two projects that need different versions of the same library will fight. The fix is a virtual environment: a per-project folder holding its own interpreter link and its own installed packages, created with python -m venv and activated before you work. It is not optional discipline. Make one per project, from the first project.

The tooling around this has churned for years - pip, virtualenv, pipenv, poetry, conda in the science world, each solving an overlapping slice. The current consolidation is uv, a single fast tool that installs interpreters, manages virtual environments, and resolves dependencies. If you are starting today, learn what a virtual environment is with venv so the concept is clear, then use whatever your team already uses.

Python 2 and Python 3

Searching for Python help still turns up two incompatible versions of the language, so it is worth thirty seconds. Python 3 arrived in 2008 as a deliberate break with Python 2, fixing design decisions - most consequentially how text and bytes are handled - that could not be fixed compatibly. The two were not interchangeable, the migration took over a decade, and it was the defining argument of the community for most of that time.

It is over. Python 2 reached end of life on 1 January 2020 and receives no fixes of any kind, including security fixes. Every current version is Python 3.

The only thing you need from this history is a filter for search results: an answer that calls print a statement rather than a function, or wraps it without parentheses, is Python 2 and will not run. Check the date on the page and move on to a newer one.

References