Mungomash LLC
Python Versions

1991 – 2025

Python Versions

Every public release of Python — from Python 0.9.0 in February 1991 through Python 3.14 in October 2025 — with end-of-life dates, current support state, and the major changes per version. Plus the Python 2 / 3 split, Guido van Rossum's July 2018 resignation, the Steering Council, the Faster CPython project, and the free-threaded / no-GIL push.

Era & support

Era

1.x — Python 0.9.0 – 1.6, 1991–2000, the CWI / CNRI origins
2.x — Python 2.0 – 2.7, 2000–2020, the long mature line (EOL January 1, 2020)
3.x — Python 3.0+, 2008 onward, the modern line

Support

Bugfix — currently receiving feature and bug fixes (newest two releases)
Security — security updates only; no further bug fixes
EOL — past its support window; no further updates from python.org

Python's release cadence is annual; each release gets ~2 years of bugfix support followed by ~3 years security-only. See PEP 602 for the policy and devguide.python.org/versions for the live status table.

Python version table

Version
Python 3.14
3.x
Bugfix
EOL Oct 2030
Oct 7, 2025
Latest release. Deferred annotations (PEP 649); template strings (PEP 750); free-threaded officially supported (PEP 779).
  • Deferred evaluation of annotations (PEP 649) — replaces the long-standing PEP 563 from __future__ import annotations approach; annotations are now lazily evaluated by default via descriptor protocol, fixing the long-running typing-runtime / forward-reference impedance mismatch.
  • Template strings (PEP 750) — new t"..." literal that produces a structured Template object instead of an immediately interpolated string, enabling safe HTML / SQL / shell composition without escaping by the template author.
  • Free-threaded CPython is officially supported (PEP 779) — the no-GIL build introduced experimentally in 3.13 graduates to a supported build, though still not the default. Phase 2 of 3 in the multi-release rollout plan.
  • PEP 768 safe external debugger interface; PEP 784 Zstandard support in the standard library.
  • PEP 758 — except* can omit parentheses around a single exception type, matching the older except shape.
  • Continued error-message improvements; the experimental JIT introduced in 3.13 keeps maturing toward production-default territory.
  • Hugo van Kemenade as release manager. Confirm latest point release against python.org/downloads.
Version
Python 3.13
3.x
Bugfix
EOL Oct 2029
Oct 7, 2024
Free-threaded build (PEP 703, experimental); experimental JIT (PEP 744); revamped REPL with multiline editing.
  • Free-threaded CPython (PEP 703) — experimental build, enabled with --disable-gil, that removes the Global Interpreter Lock for true parallel multi-threaded execution. The single biggest CPython runtime change since 3.0; led by Sam Gross at Meta starting 2021. Graduated to officially supported in 3.14.
  • Experimental JIT (PEP 744) — copy-and-patch tier-2 JIT, opt-in at build time. Foundation for the multi-release performance work ongoing in the Faster CPython project.
  • New interactive interpreter — multiline editing, color, paste-friendly, F1/F2/F3 help / history / paste-mode, ported from PyPy's pyrepl.
  • Mobile platforms reach Tier 3: iOS (PEP 730) and Android (PEP 738) are formally supported targets.
  • Improved error messages continue (better suggestions on NameError / ImportError); typing improvements (typing.TypeIs, typing.ReadOnly, defaults for type parameters via PEP 696).
  • Standard-library cleanup: PEP 594 "dead batteries" finally removed (aifc, chunk, cgi, nis, pipes, sndhdr, telnetlib, and others).
  • Thomas Wouters as release manager.
Version
Python 3.12
3.x
Security
EOL Oct 2028
Oct 2, 2023
Per-interpreter GIL (PEP 684); type parameter syntax (PEP 695); f-string formal grammar (PEP 701).
  • Per-interpreter GIL (PEP 684) — subinterpreters can each have their own GIL, enabling true parallelism via the C API even before the free-threaded build landed in 3.13.
  • Type parameter syntax (PEP 695) — def first[T](items: list[T]) -> T as a native generic syntax replacing the older TypeVar import dance; type Alias = ... as a native type-alias statement.
  • f-string formal grammar (PEP 701) — f-strings are now part of the language grammar instead of a separate ad-hoc parser; nested quotes, multi-line expressions, comments, and backslashes inside f-strings finally work.
  • PEP 698 @override decorator for typing.
  • Comprehension inlining — ~2x speedup on list / dict / set comprehensions by no longer allocating a separate frame.
  • distutils removed (deprecated since 3.10); setuptools is now the only path. pathlib, asyncio, and typing all see broad improvements.
  • Continued error-message improvements; better support for buffer protocol via PEP 688.
  • Thomas Wouters as release manager.
Version
Python 3.11
3.x
Security
EOL Oct 2027
Oct 24, 2022
First Faster CPython release (10–60% speedup); fine-grained tracebacks; exception groups; Self type; tomllib.
  • First Faster CPython release — the multi-year project funded by Microsoft and led by Mark Shannon delivered 10–60% real-world speedups (1.25x geometric mean across the official benchmark suite) without any source change. Adaptive specializing interpreter (PEP 659) is the load-bearing piece.
  • Fine-grained tracebacks (PEP 657) — tracebacks now point at the exact column / sub-expression that raised, not just the line. The single biggest debugging-quality-of-life improvement of the modern era.
  • Exception groups and except* (PEP 654) — raise / catch multiple unrelated exceptions together. Foundation for asyncio task-group error handling.
  • PEP 673 Self type; PEP 646 variadic generics; PEP 681 dataclass transforms.
  • tomllib in the standard library — TOML parsing finally without a third-party dependency.
  • PEP 678 exception .add_note(); asyncio TaskGroup; StrEnum.
  • Pablo Galindo as release manager.
Version
Python 3.10
3.x
Security
EOL Oct 2026
Oct 4, 2021
match statement (PEP 634); X | Y union syntax; parenthesized context managers; better error messages.
  • Structural pattern matching (PEP 634) — match / case statement with destructuring patterns. Years of contention before acceptance; the largest new syntactic feature since async / await.
  • Union syntax with | (PEP 604) — int | str as runtime-supported syntax for Union[int, str]; isinstance with |.
  • Vastly better error messages — missing-colon, missing-comma, unmatched-paren, and invalid-keyword diagnostics get specific suggestions. The Pablo-Galindo / Lysandros Nikolaou parser rewrite paying compounding dividends.
  • Parenthesized context managers (multi-line with); precise line numbers for tracebacks.
  • typing.ParamSpec (PEP 612), TypeAlias, TypeGuard; dataclass(slots=True, kw_only=True).
  • Pablo Galindo as release manager.
Version
Python 3.9
3.x
EOL
Oct 5, 2025
Oct 5, 2020
Generics in standard collections (list[int]); dict union | / |=; str.removeprefix() / removesuffix(); zoneinfo.
  • Generics in standard collections (PEP 585) — list[int] works at runtime instead of needing List[int] from typing. The first big "we no longer need to import from typing" wave.
  • Dict union (PEP 584) — {**a, **b} got an operator: a | b and in-place a |= b.
  • str.removeprefix(x) and str.removesuffix(x) — an end to the lstrip/rstrip-as-prefix-removal misuse.
  • zoneinfo (PEP 615) — IANA time-zone support in the standard library; replaced the third-party pytz dependency for most uses.
  • Relaxed grammar restrictions on decorators (PEP 614); first release built with the new PEG parser (PEP 617) instead of LL(1).
  • First release on the new annual cadence per PEP 602; Łukasz Langa as release manager.
Version
Python 3.8
3.x
EOL
Oct 7, 2024
Oct 14, 2019
Walrus operator := (PEP 572); positional-only parameters; f-string = debug; typing.Protocol, TypedDict, Literal, Final.
  • Walrus operator — := (assignment expressions, PEP 572). The syntactic decision so contentious that Guido van Rossum resigned as BDFL over the surrounding debate (see the prose history below).
  • Positional-only parameters (PEP 570) — the / separator in function signatures; finally a way for pure-Python functions to express what C functions had always been able to.
  • f-string self-documenting expressions — f"{x=}" prints "x=value", a debugging shorthand.
  • Typing additions: Protocol (PEP 544, structural subtyping), TypedDict, Literal, Final.
  • importlib.metadata for package metadata access; functools.cached_property.
  • Łukasz Langa as release manager (the first Steering-Council-era release).
Version
Python 3.7
3.x
EOL
Jun 27, 2023
Jun 27, 2018
dataclasses; contextvars; breakpoint(); dict insertion order officially guaranteed; async / await become reserved keywords.
  • dataclasses (PEP 557) — the @dataclass decorator. Took most of the wind out of the third-party attrs library and reset how Python developers wrote plain-data classes.
  • Dict insertion order officially guaranteed (was implementation detail in 3.6; promoted to language guarantee here).
  • contextvars (PEP 567) — thread-local-equivalent state that works correctly across async tasks.
  • breakpoint() (PEP 553) builtin; async and await become reserved keywords (no more identifier conflicts in libraries).
  • Postponed evaluation of annotations (PEP 563) introduced as opt-in via from __future__ import annotations; replaced by PEP 649 in 3.14.
  • Last release Guido shipped as BDFL — Guido stepped down on July 12, 2018, two weeks after this release.
Version
Python 3.6
3.x
EOL
Dec 23, 2021
Dec 23, 2016
f-strings (PEP 498); variable annotations; async generators / comprehensions; compact dict (insertion-ordered as implementation detail).
  • f-strings — f"hello {name}" formatted string literals (PEP 498). Quietly the most consequential post-3.0 syntactic change in adoption terms.
  • Variable annotations (PEP 526) — x: int = 5 beyond function signatures, completing the gradual-typing surface.
  • Compact dict — CPython implementation rewrite; dicts use 20–25% less memory and (as a side effect) preserve insertion order. Officially promoted to language guarantee in 3.7.
  • Async generators / async comprehensions (PEP 525, PEP 530).
  • Underscores in numeric literals (1_000_000); secrets module; typing.NamedTuple with class syntax.
  • __init_subclass__ and __set_name__ hooks; the broader pathlib gets first-party love.
Version
Python 3.5
3.x
EOL
Sep 30, 2020
Sep 13, 2015
async / await syntax (PEP 492); type hints (PEP 484); matrix multiplication operator @; typing module.
  • async / await syntax (PEP 492) — native coroutine syntax. The asyncio library shipped in 3.4 had used generator-based @coroutine + yield from; this release gave it real syntax. Set the stage for the modern Python async ecosystem (FastAPI, Starlette, aiohttp, async SQLAlchemy).
  • Type hints (PEP 484) — the typing module; the multi-year mypy / typeshed / type-stubs ecosystem starts here.
  • Matrix multiplication operator @ (PEP 465) for NumPy and the scientific stack.
  • Unpacking generalizations: {*a, *b}, {**a, **b} in function calls and literal contexts (PEP 448).
  • os.scandir(); subprocess.run(); HTTPS by default in http.client.
Version
Python 3.4
3.x
EOL
Mar 18, 2019
Mar 16, 2014
asyncio (PEP 3156); ensurepip; enum; pathlib (provisional); statistics.
  • asyncio (PEP 3156, codenamed Tulip during development) — the first official async event loop in the standard library. Generator-based @coroutine in 3.4; native syntax in 3.5.
  • ensurepip (PEP 453) — pip ships with Python; the long bootstrap problem ends. CPython 3.4+ guarantees pip is available.
  • enum module (PEP 435); pathlib (provisional) (PEP 428); statistics module (PEP 450).
  • Single-dispatch generic functions (functools.singledispatch); tracemalloc.
  • The first 3.x release that finally felt "complete" to most working Python developers; broader 3.x adoption begins around here.
Version
Python 3.3
3.x
EOL
Sep 29, 2017
Sep 29, 2012
yield from; u'unicode' literal back; venv; namespace packages (PEP 420).
  • yield from (PEP 380) — sub-generator delegation; the load-bearing piece for the upcoming asyncio coroutine pattern.
  • u'unicode' literal restored — the 3.0 removal had broken too many polyglot 2/3 codebases; bringing it back made Python 2-and-3 source-compatible code possible.
  • venv module — virtual environments without third-party tooling.
  • Namespace packages (PEP 420); implicit namespace packages without __init__.py.
  • unittest.mock in the standard library; key-sharing dictionaries; flexible string representation (PEP 393) reduces memory use of strings.
Version
Python 3.2
3.x
EOL
Feb 20, 2016
Feb 20, 2011
argparse; concurrent.futures; functools.lru_cache; stable ABI (PEP 384).
  • argparse module (PEP 389) — replaced optparse as the recommended command-line parser.
  • concurrent.futures (PEP 3148) — Thread/ProcessPoolExecutor in the standard library.
  • functools.lru_cache — bounded memoization decorator, ubiquitous in modern Python code.
  • Stable ABI (PEP 384) for C extensions.
  • Hash randomization for strings (security mitigation against algorithmic-complexity attacks).
Version
Python 3.1
3.x
EOL
Apr 9, 2012
Jun 27, 2009
OrderedDict; Counter; dict / set comprehensions; faster I/O.
  • OrderedDict and Counter in collections.
  • Dict and set comprehensions ({k: v for k, v in items}).
  • Significantly faster I/O on the new io module from 3.0.
  • The cleanup release that made 3.0's design directionally usable.
Version
Python 3.0
3.x
EOL
Jun 27, 2009
Dec 3, 2008
The big break. print() as a function; str / bytes split; new I/O system; the eleven-year migration begins.
  • The deliberate backwards-incompatible break — print() as a function; str is Unicode by default with a separate bytes type; integer division returns float by default (1 / 2 == 0.5); range() is a lazy iterator.
  • Removed: reduce as a builtin (moved to functools), print statement, <> operator, raise X, Y syntax, except X, Y syntax, classic classes (everything is new-style now), backticks for repr.
  • Function annotations (PEP 3107) — metadata syntax with no specified semantics; would later become the foundation for type hints in 3.5.
  • Keyword-only arguments; metaclass syntax; nonlocal keyword.
  • Shipped with the migration tool 2to3 and an explicit deprecation runway. Even so, the practical migration of the Python ecosystem took until January 1, 2020 — eleven years — to complete (see the prose history).

The Python 3 split — December 2008. Above this line: the modern 3.x line that began with the deliberate backwards-incompatible break in December 2008. Below: the 2.x line that ran from 2000 through January 1, 2020 — the longest-running parallel-line transition in the history of any major language. The 2 / 3 migration story has its own prose section below.

Version
Python 2.7
2.x
EOL
Jan 1, 2020
Jul 3, 2010
The long-tail bridge release. Backported features from early 3.x; received nearly a decade of support after the 2.7 line was supposed to end in 2015.
  • The longest-supported release in Python history. Originally scheduled to EOL in 2015; extended to January 1, 2020 ("Sunset Day"), giving the ecosystem an unprecedented ten-year tail to migrate to 3.x.
  • Backports from early 3.x: dict and set comprehensions, OrderedDict, Counter, argparse, memoryview, the {:format} spec, the new io module.
  • argparse from 3.2 backported; collections.OrderedDict from 3.1.
  • Unified numbers ABC hierarchy; dict view objects.
  • EOL coverage in the Python community was enormous — the Python Sunset page on python.org and pythonclock.org ran a literal countdown for years.
  • The last Python 2.7 release was 2.7.18 on April 20, 2020 — technically post-EOL, shipped as a final farewell.
Version
Python 2.6
2.x
EOL
Oct 29, 2013
Oct 1, 2008
Bridge to Python 3 release. __future__ imports for 3.x semantics; multiprocessing; abc.
  • The transition release. Shipped two months before 3.0; designed so 2.x code could opt into individual 3.x semantics via from __future__ import ....
  • print_function, unicode_literals, division, absolute_import as __future__ opt-ins.
  • multiprocessing module — native subprocess-based parallelism around the GIL.
  • abc module for abstract base classes (PEP 3119 backport).
  • str.format() method as the new format string syntax (eventually superseded by f-strings in 3.6).
Version
Python 2.5
2.x
EOL
May 26, 2011
Sep 19, 2006
with statement (PEP 343); conditional expressions; yield as expression (coroutines); ctypes.
  • with statement (PEP 343) — context managers; with open(f) as fp: as the canonical resource-management pattern.
  • Conditional expressions (PEP 308): x if cond else y.
  • Generators as coroutines — yield becomes an expression that can receive values via .send(); the generator-based-coroutine pattern that asyncio in 3.4 would build on.
  • ctypes in the standard library — FFI to C without writing a C extension.
  • Absolute and relative imports become defaults; any() and all() built-ins.
Version
Python 2.4
2.x
EOL
Dec 19, 2008
Nov 30, 2004
Decorators (@ syntax); generator expressions; built-in set type; subprocess.
  • Decorator syntax (PEP 318) — @decorator above function definitions. Reshaped how Python frameworks (Flask, Django, pytest, FastAPI) expose their APIs.
  • Generator expressions ((x for x in items)); built-in set and frozenset types (replacing the sets module).
  • subprocess module (PEP 324) — eventually superseded the older os.popen family.
  • collections module introduced (initially with deque; defaultdict came in 2.5).
  • decimal module for fixed-point arithmetic.
Version
Python 2.3
2.x
EOL
Jun 11, 2008
Jul 29, 2003
enumerate(); sets module; logging; the import system gets a rewrite.
  • enumerate() built-in.
  • sets module (Python-level; later replaced by built-in set in 2.4).
  • logging module — the canonical structured-logging interface.
  • Boolean type promoted from "True / False as integers" to a proper type.
  • Date / time improvements; the heapq module gets richer.
Version
Python 2.2
2.x
EOL
May 30, 2003
Dec 21, 2001
New-style classes — type / class unification; generators (PEP 255); iterators; super().
  • New-style classes — the object-rooted type/class unification (PEP 252, PEP 253). Cleaned up the divide between built-in types and user-defined classes; properties, descriptors, and metaclasses became user-accessible.
  • Simple generators (PEP 255) — yield keyword; the foundation for the iterator-everywhere idiom.
  • Iterators as a first-class concept (PEP 234); __iter__ protocol.
  • super() for cooperative multiple inheritance.
  • Integer / long unification (no more silent overflow on 32-bit platforms).
Version
Python 2.1
2.x
EOL
Apr 9, 2003
Apr 17, 2001
Nested scopes (closures); weakref; the Python Software Foundation is founded.
  • Nested scopes (PEP 227) — closures finally work; lexical scoping aligned with most other languages.
  • weakref module.
  • "Rich comparisons" (PEP 207); __lt__, __gt__ etc. as separate dunder methods.
  • Released under the new PSF license.
  • The Python Software Foundation was incorporated March 6, 2001, between 2.0 and 2.1.
Version
Python 2.0
2.x
EOL
Jun 22, 2001
Oct 16, 2000
List comprehensions; cycle-detecting garbage collector; Unicode strings; augmented assignment (+=).
  • List comprehensions (PEP 202) — [x*x for x in items]; the syntactic feature most associated with "Pythonic" code ever after.
  • Cycle-detecting garbage collector — reference counting plus a generational cycle collector. Eliminated the long-running "you can leak memory if your data structures form cycles" footgun.
  • Unicode strings (PEP 100) — u"..." literals; the start of the journey to 3.0's Unicode-by-default model.
  • Augmented assignment operators (+=, -=, *=, ...).
  • First release made by BeOpen.com with Guido and the team after they left CNRI; this is the lineage release where the modern Python licensing era begins.
Version
Python 1.6
1.x
EOL
long EOL
Sep 5, 2000
Last release made under CNRI auspices. Unicode strings introduced; the licensing-controversy release.
  • The last release Guido and the team made under CNRI (Corporation for National Research Initiatives). The CNRI license shipped with this release was incompatible with the GPL, briefly causing it to be excluded from Debian; the licensing got resolved in 2.0 and 2.1 onward via the PSF license.
  • Initial Unicode-string introduction (u"..." literals) — though the full Unicode-everywhere model would land in 3.0.
  • Released the same month Python 2.0 also shipped, after Guido and the core team had moved to BeOpen.com.
  • The 1.x line effectively ends here; 1.6.1 followed in 2001 to address the licensing incompatibility, but no further development.
Version
Python 1.5
1.x
EOL
long EOL
Dec 31, 1997
re module replaces regex; assert statement; the long-running stable 1.x release.
  • re module (Perl-compatible regex) replacing the older regex module.
  • assert statement.
  • 1.5 became the de-facto stable Python for years — many Linux distributions shipped it well past its release.
  • Followed by Python 1.5.1 (April 1998) and Python 1.5.2 (April 1999), the last point releases of the 1.5 line.
Version
Python 1.4
1.x
EOL
long EOL
Oct 25, 1996
Complex numbers; keyword arguments; string-literal concatenation.
  • Complex-number type as a first-class numeric type.
  • Keyword arguments in function calls (also added in this era).
  • Adjacent string-literal concatenation ("foo" "bar" ≡ "foobar").
  • First release Guido and the team made after moving from CWI in Amsterdam to CNRI in Reston, Virginia in 1995.
Version
Python 1.0
1.x
EOL
long EOL
Jan 26, 1994
Exception handling; lambda, map, filter, reduce; functions with default and keyword arguments; modules.
  • Released from CWI (Centrum Wiskunde & Informatica) in Amsterdam, where Guido had been working since 1989.
  • Exception-handling syntax (try / except / finally).
  • Functional-programming primitives: lambda, map, filter, reduce — contributed by Amrit Prem from a "Lisp lover" outside the core team.
  • Functions with default and keyword arguments.
  • The module system; import; from ... import ....
  • Followed by 1.0.1 (Feb 1994), 1.1 (Oct 1994), 1.2 (Apr 1995), 1.3 (Oct 1995) at CWI.
Version
Python 0.9.0
1.x
EOL
long EOL
Feb 20, 1991
First public release. Posted to alt.sources by Guido van Rossum from CWI in Amsterdam.
  • First public release of Python, posted by Guido van Rossum to the Usenet newsgroup alt.sources on February 20, 1991. The implementation work had begun over Christmas 1989 at CWI as a "hobby project" to keep him busy during the holiday office closure.
  • Already had: classes with inheritance, exception handling, functions, the core data types (string, list, dictionary), module system, basic I/O.
  • Named after Monty Python's Flying Circus, not the snake. (The snake imagery came later, after the language got popular.)
  • Internal pre-public versions had circulated within CWI starting in 1989 as Python's prototype was developed alongside the ABC programming language work, which Guido had been involved in.
  • Originally intended to be a "scripting language to replace shell scripts and Perl" for system-administration work.

Click any row to expand. Each row has a stable id for sharing — e.g. /data/python/versions/#python-3-13, #python-2-7, #python-0-9-0. Live release / EOL state is documented at devguide.python.org/versions.

The 1989 origin and the CWI years

Python was started by Guido van Rossum at Centrum Wiskunde & Informatica (CWI) in Amsterdam over Christmas 1989. CWI's offices were closed for the holiday and Guido, by his own account, was looking for a "hobby project" to keep himself busy. He had been working on the ABC programming language at CWI for several years and wanted to design a successor that fixed ABC's weaknesses (closed-world implementation, no extensibility) while keeping its readability.

The first public release — Python 0.9.0 — went up on the Usenet newsgroup alt.sources on February 20, 1991. Already complete were classes with inheritance, exception handling, functions, the core data types (string, list, dictionary), and a module system. The name was a Guido in-joke about Monty Python's Flying Circus — the snake imagery was retro-fitted to it after the language became popular. Guido stayed at CWI through Python 1.3 in October 1995, then moved to the Corporation for National Research Initiatives (CNRI) in Reston, Virginia in 1995, where Python 1.4 through 1.6 shipped. He left CNRI in 2000 to join BeOpen.com, then Zope Corporation in 2003, then Google in 2005, then Dropbox in 2013, then Microsoft in late 2020.

The Python Software Foundation

The Python Software Foundation was incorporated as a 501(c)(3) non-profit on March 6, 2001, between Python 2.0 and 2.1. The PSF holds the copyright to Python and its standard library, runs python.org, sponsors PyCon and the regional Python conferences, administers the PSF License Agreement under which Python is released, and (since 2018) holds the cpython repository on GitHub. The PSF is the structural answer to the question "who owns Python." It is supported by corporate sponsorship from many of the largest companies that use Python and by individual donations. The PSF and the Steering Council (introduced in 2019) are independent: the PSF is the legal entity; the Steering Council is the technical-direction body.

The Python 2 / 3 split — the eleven-year migration (2008–2020)

Python 3.0 shipped on December 3, 2008 as a deliberate, explicit backwards-incompatible break with the 2.x line. The headline changes — print() as a function, Unicode by default with a separate bytes type, integer division returning float, range() as a lazy iterator — were small compared to the cumulative impact: every meaningful Python project had to either port to 3.x or freeze on 2.x.

The migration was projected to take "a few years." It took eleven. Python 2.7 was originally scheduled to EOL in 2015; after community pushback the date was extended to January 1, 2020 — the famous Sunset Day — with one final release (Python 2.7.18, April 20, 2020) shipped post-EOL as a farewell. The countdown ran on pythonclock.org; major projects (Django, NumPy, scipy, Twisted) progressively dropped 2.x support starting in 2020. Some long-tail systems (especially in scientific computing, ops scripting, and embedded-Linux distributions) carried Python 2 well past EOL. Red Hat Enterprise Linux 7 shipped with Python 2.7 as the system Python through its 2024 EOL.

The migration informed every subsequent Python language-design decision: backward compatibility within 3.x is now treated as load-bearing, deprecation cycles are explicit and multi-release, and __future__-style opt-in is the default mechanism for previewing semantic changes. The 2 / 3 break is also the most-cited example of "what not to do" in language-versioning discussions for any language project considering a major break since.

The PEP process — Python's design culture

Python Enhancement Proposals (PEPs) were introduced by Barry Warsaw, Jeremy Hylton, and Guido in 2000, modeled loosely on the IETF's RFC process and Java's JSR. Every meaningful change to the language, the standard library, or the development process gets a PEP: the canonical archive is at peps.python.org. PEPs are numbered in order of submission, and a small set of foundational PEPs (PEP 1: PEP purpose; PEP 8: style guide; PEP 20: The Zen of Python; PEP 257: docstring conventions; PEP 484: type hints) get cited so heavily they've become Python culture as much as Python policy. The PEP system is the most widely-imitated language-design convention in software, with parallels in JEP (Java Enhancement Proposal), TC39 ECMAScript proposals, Rust RFCs, Swift Evolution, and others.

Guido's resignation and the Steering Council (2018–2019)

On July 12, 2018, Guido posted to python-committers that he was stepping down as Benevolent Dictator for Life. The immediate trigger was PEP 572 (the walrus operator := for assignment expressions). The PEP had been deeply contentious; Guido had ultimately accepted it over significant community opposition; the post-acceptance reaction had been emotionally exhausting. From the resignation post:

"Now that PEP 572 is done, I don't ever want to have to fight so hard for a PEP and find that so many people despise my decisions. ... I would like to remove myself entirely from the decision process. I'll still be there for a while as an ordinary core dev, and I'll still be available to mentor people — possibly more available. But I'm basically giving myself a permanent vacation from being BDFL, and you all will be on your own."

Governance was undefined for several months. PEP 8016 was accepted in December 2018, establishing a five-member Steering Council elected by the core developers. The first council was elected in January 2019 and consisted of Barry Warsaw, Brett Cannon, Carol Willing, Guido van Rossum, and Nick Coghlan. Guido has continued to serve on subsequent councils intermittently. The transition is widely cited as one of the smoothest BDFL-to-collective-governance handoffs in any language community.

The Faster CPython project (2020–)

In 2020, Microsoft hired Mark Shannon — a long-time CPython contributor with a history of CPython-performance research — to lead a multi-year project aimed at making CPython significantly faster. Microsoft also brought Guido van Rossum, who had been retired from Dropbox, on staff to support the project. The Faster CPython team has shipped a major performance contribution to every CPython release from 3.11 onward.

Python 3.11 (October 2022) delivered the headline 10–60% real-world speedup (1.25x geometric mean across the official benchmark suite), driven primarily by the adaptive specializing interpreter (PEP 659). Subsequent releases extended the work: comprehension inlining in 3.12, the experimental copy-and-patch JIT (PEP 744) in 3.13, the JIT continuing to mature in 3.14. The work is publicly tracked in the faster-cpython/ideas GitHub repository.

The free-threaded / no-GIL push (2023–)

The Global Interpreter Lock — the CPython mutex that prevents multiple threads from executing Python bytecode simultaneously — has been the single most-debated piece of CPython's design since the 1990s. Multiple "GIL-removal" attempts had failed over the years, usually because they made single-threaded performance significantly worse. In 2021, Sam Gross at Meta produced a fork (nogil) demonstrating GIL removal with acceptable single-threaded overhead. PEP 703 formalized the proposal; the Steering Council accepted it in 2023 with an explicit multi-release rollout plan: experimental in 3.13 (October 2024), officially supported via PEP 779 in 3.14 (October 2025), default-on planned for a future release pending performance and ecosystem readiness. PEP 684's per-interpreter GIL in 3.12 was the parallel C-API track for the same goal.

The typing arc — from PEP 484 to native syntax

Function annotations as syntactic surface (PEP 3107) shipped in 3.0 with no specified semantics. Six years later, PEP 484 in 3.5 (September 2015) gave them meaning as type hints, alongside the typing module and the typeshed standard-library type-stub project. mypy, started by Jukka Lehtosalo as a research project, became the canonical type-checker; later joined by Microsoft's pyright (now the engine behind Pylance in VS Code), Meta's Pyre, and Astral's ty.

The subsequent multi-release work has steadily pulled type expressivity into the language proper: variable annotations in 3.6, dataclasses and from __future__ import annotations in 3.7, Protocol / TypedDict / Literal / Final in 3.8, generics in standard collections in 3.9 (PEP 585), X | Y union syntax in 3.10 (PEP 604), Self and ParamSpec in 3.11, native type-parameter syntax in 3.12 (PEP 695), defaults for type parameters in 3.13 (PEP 696), and PEP 649's deferred-evaluation rewrite in 3.14. Type hints are now load-bearing for FastAPI, Pydantic, SQLAlchemy 2.x, the Astral toolchain (uv / ruff / ty), and the long tail of modern Python web and data tooling.

Alternative implementations

CPython is the reference implementation, but several others have shaped the ecosystem:

  • PyPy — the long-running Python-in-Python implementation with a tracing JIT, started in 2003. Routinely 4–10x faster than CPython on long-running pure-Python workloads. The PyPy team's pyrepl was the basis of the new interactive interpreter that landed in CPython 3.13.
  • Jython — Python on the JVM, started by Jim Hugunin in 1997. Mostly stuck on Python 2.7 in modern usage; a Python 3 port is in long-running development.
  • IronPython — Python on the .NET CLR, also started by Jim Hugunin (2006), then maintained by Microsoft until being open-sourced and community-led. Python 3 support shipped in IronPython 3 (2021).
  • MicroPython — Damien George's 2013 implementation for microcontrollers. Runs on the BBC micro:bit and a long tail of embedded platforms. CircuitPython is Adafruit's MicroPython fork tuned for hardware education.
  • Pyston — a JIT'd CPython fork from Dropbox; the technology's lessons fed back into the Faster CPython project.
  • Cinder — Meta's internal CPython fork with a JIT and immortal objects; immortal-object support was upstreamed into 3.12 (PEP 683).
  • Mojo — Chris Lattner's superset language (started 2023) with Python-compatible syntax and AOT-compiled performance for ML / GPU workloads. Not a CPython implementation per se, but positions itself as Python-compatible.
  • RustPython — Python interpreter written in Rust; experimental, browser-targetable via WebAssembly.

The packaging story — distutils to uv

Python's packaging history has been famously messy. distutils shipped in Python 1.6 (2000) and was the standard library's answer to "how do I distribute a package." setuptools (2004) added install-from-source / dependency-resolution; easy_install was its installer. pip (2008) replaced easy_install and shipped with CPython itself starting in 3.4 via ensurepip. virtualenv (2007) became venv in the standard library in 3.3.

The 2010s through early 2020s brought conda (Continuum Analytics, 2012; for the scientific stack), pipenv (2017; lockfile-and-virtualenv combo from Kenneth Reitz), and Poetry (2018; pyproject.toml-driven dependency management and build system). The PSF-sanctioned standardization track ran through PEP 517 (build-system independence), PEP 518 (pyproject.toml), PEP 621 (project metadata in pyproject.toml), and PEP 660 (editable installs). In 2024, Astral's uv (a Rust-based pip / pip-tools / virtualenv / pyenv replacement, ~10–100x faster than its predecessors) took the modern packaging conversation by storm, alongside Astral's ruff (linter / formatter) and ty (type-checker). The "what's the canonical Python toolchain" question is quietly being re-answered for the first time in a decade.

People who actually shaped Python

Original / BDFL era: Guido van Rossum (creator and BDFL 1991–2018), Tim Peters (longtime core dev, author of The Zen of Python and Timsort, the sort algorithm CPython has used since 2002 and which Java / Android / Swift later adopted), Barry Warsaw (PEP 1 author, mailman / Mailman, longtime release manager), Jeremy Hylton (PEP 1 co-author, early Google Python team), Andrew Kuchling (PEP author, "What's New in Python N" tradition).

Modern Steering Council and core team: Brett Cannon (Steering Council; Python 3 import-system rewrite; core dev since 2003), Carol Willing (Steering Council; Project Jupyter), Nick Coghlan (Steering Council; importlib; Red Hat / Cloudera), Pablo Galindo Salgado (Steering Council; PEG parser, fine-grained tracebacks, 3.10 / 3.11 release manager; Bloomberg), Łukasz Langa (3.8 / 3.9 release manager; PSF; Black formatter author), Thomas Wouters (3.12 / 3.13 release manager; Google), Hugo van Kemenade (3.14 release manager), Mark Shannon (Microsoft Faster CPython lead; specializing-interpreter architect), Sam Gross (Meta; PEP 703 / nogil author), Petr Viktorin (Red Hat; stable ABI), Victor Stinner (Red Hat; many performance and security fixes).

Typing lineage: Jukka Lehtosalo (mypy creator), Łukasz Langa, Eric Traut (Microsoft; pyright author), Guido (PEP 484 co-author and Dropbox / Microsoft typing-team lead). Astral / packaging lineage: Charlie Marsh (uv / ruff / ty author at Astral). Async lineage: Yury Selivanov (uvloop, asyncpg, async generators / context managers, PEP 492 native coroutines). Scientific stack: Travis Oliphant (NumPy / SciPy / Anaconda / Numba), Wes McKinney (pandas).

Find your version — in the terminal

The browser cannot detect what version of Python is installed on your machine — there's no UA Client Hint or fingerprint that exposes it. Run one of these in your terminal to see your real install.

What's installed?

Print the active interpreter, where it lives on disk, and the full version tuple.

$ python --version                      # may resolve to 2.7 on older macOS / Linux
$ python3 --version                     # the canonical "real Python" launcher on macOS / Linux
$ which python3                          # where the binary lives
$ python3 -c "import sys; print(sys.version_info)"
> py --version                          # Windows: the Python Launcher
> py -0                                  # Windows: list every Python installed

Pin a project to a specific Python

Modern Python projects pin via pyproject.toml for tooling and a .python-version file for version managers.

# pyproject.toml
[project]
name = "my-app"
requires-python = ">=3.11"

# .python-version (read by pyenv, asdf, uv)
3.13.0

requires-python takes any PEP 440 version specifier (>=3.11, ~=3.12.0, >=3.10,<3.14).

Install or upgrade a version

Multiple Pythons can coexist; installing a new one doesn't remove old ones.

# macOS (Homebrew)
$ brew install python@3.13
$ brew install python@3.12               # side-by-side, both kept

# Windows (winget)
> winget install Python.Python.3.13
> winget install Python.Python.3.12

# Linux (apt / dnf / pacman; per-distro Python package)
$ sudo apt install python3.13            # Debian / Ubuntu (or deadsnakes PPA for newer)
$ sudo dnf install python3.13            # Fedora / RHEL

# Official installer: https://www.python.org/downloads/
# Source build via pyenv (any version, any platform):
$ pyenv install 3.13.0
$ pyenv install 3.14.0

Manage multiple Pythons & per-project venvs

A version manager picks the interpreter; a virtual environment isolates the dependencies.

# Built-in: virtualenvs without third-party tooling
$ python3 -m venv .venv
$ source .venv/bin/activate               # macOS / Linux
> .venv\Scripts\activate                  # Windows

# pyenv: classic version manager (macOS / Linux)
$ pyenv versions                          # list installed Pythons
$ pyenv global 3.13.0                     # default for this user
$ pyenv local 3.12.7                      # pin for the current directory tree

# uv (Astral): fast modern Python + venv + package manager
$ uv python install 3.13                  # grab the interpreter
$ uv venv                                 # create a venv in .venv/
$ uv pip install -r requirements.txt    # install into the venv

# conda (scientific stack)
$ conda create -n myenv python=3.13
$ conda activate myenv

Sources: python.org/downloads; devguide.python.org/versions; PEP archive; CPython release notes; What's New in Python; Python Software Foundation; Guido's July 2018 resignation post; and the books and contemporaneous reporting cited inline. Last updated April 2026.

Mungomash LLC · More data pages