1991 – 2026

Python Versions

Every public release of Python — from Python 0.9.0 in February 1991 through Python 3.15 in October 2026 — 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 bug fixes and security 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.15
3.x
Bugfix
EOL Oct 2031
Oct 9, 2026
Latest release. Explicit lazy imports (PEP 810); frozendict / sentinel builtins; UTF-8 as the default encoding (PEP 686); stable ABI for free-threaded builds (PEP 803).
  • Explicit lazy imports (PEP 810) — a new lazy soft keyword (lazy import json, lazy from pathlib import Path) binds a lightweight proxy and defers the real module load until the name is first used, so a large application can keep every import at the top of the file without paying startup cost for modules a given run never touches.
  • New builtins and language changes — frozendict (PEP 814) and sentinel (PEP 661) built-in types; UTF-8 is the default encoding regardless of locale (PEP 686), so open('f.txt') with no encoding argument reads UTF-8 on every platform (PYTHONUTF8=0 restores the old behaviour); unpacking in comprehensions (PEP 798); .start files (PEP 829) replace the executable import lines in .pth files as the auditable way to run code at interpreter startup; a math.integer submodule (PEP 791).
  • Profiling and observability — a dedicated profiling package (PEP 799) whose profiling.sampling module is Tachyon, a statistical sampling profiler that attaches to a running process without a restart and samples at up to 1,000,000 Hz; CPython is now built with frame pointers by default (PEP 831) so system profilers and eBPF tools can unwind through it.
  • Free-threading reaches the stable ABI — abi3t (PEP 803, with the PEP 793 PyModExport entry point and PEP 820 PySlot) lets one compiled extension binary target free-threaded builds across Python versions, and the official macOS binaries now install free-threading support by default. The free-threaded build is still not the default build; the prose section below has the rollout state.
  • Performance — the still-experimental JIT gains an LLVM 21 build-time dependency, a tracing frontend, basic register allocation and better code generation: a 7–8% geometric-mean gain over the fully optimized interpreter on x86-64 Linux and 11–12% over the tail-calling interpreter on AArch64 macOS, per the What's New's September 25, 2026 benchmark run. The official Windows 64-bit binaries switch to the tail-calling interpreter (15–20% over the switch-case interpreter on pyperformance). mimalloc now backs raw memory allocations (PyMem_RawMalloc()), aimed at free-threaded builds; base64 encodes 2x and decodes 3x faster.
  • Typing: TypedDict with typed extra items (PEP 728), TypeForm (PEP 747), disjoint bases (PEP 800). C API: PyBytesWriter (PEP 782) and protection against interpreter finalization (PEP 788). More color across the standard-library command-line tools and in tab completion, which now also suggests attributes inside from … import.
  • Release history: 5,643 commits from 1,012 contributors since 3.14. rc1 on August 4, 2026 froze the ABI; rc2 followed on September 1; then a surprise rc3 on October 2 carried last-minute lazy-import release blockers and pushed the final from its scheduled October 1 to October 9, 2026. Hugo van Kemenade as release manager, his second after 3.14. The first two maintenance releases came early and back to back, both expedited security releases over the eMudhra / emSign certificate-authority key compromise: 3.15.1 on October 21, 2026 (bundled pip 26.2.2 with the cleaned-up certifi, plus Expat 2.9.0) and 3.15.2 on October 25 (an ssl-level block on the compromised keys; see the security note below). Next per PEP 790: 3.15.3 on December 1, 2026, then a bugfix release roughly every two months until October 2028, and source-only security fixes to October 2031. The 3.16 cycle opened with 3.16.0a1 on October 13, 2026 under release manager Savannah Ostrowski; PEP 826 schedules 3.16.0a2 for November 10, 2026 and 3.16.0 for October 5, 2027.
  • Security: 3.15.0 shipped with every CPython advisory published before it already closed, including the three that landed in the final stretch and went into the October 2 rc3. CVE-2026-19445 (CVSS 4.0 base 9.2 Critical from the Python Software Foundation as CNA; NVD analysis still pending) is a use-after-free of a server-side ssl.SSLContext: when an sni_callback switches a connection to a different context and nothing else keeps the original alive, a remote, unauthenticated TLS client can crash the server or make it call through a freed pointer (gh-156293). CVE-2026-19553 (7.6 High) — SSLContext.wrap_bio() silently skipped hostname verification when server_hostname was omitted with check_hostname on (gh-156793). Both were published September 30, 2026. CVE-2026-12345 (5.9 Medium), published September 29, is a race in tempfile.TemporaryDirectory cleanup: an attacker who can swap a directory for a symbolic link mid-cleanup can get files outside the temporary tree deleted or have their permissions reset (gh-157579). On the maintenance lines, the expedited 3.14.8 and 3.13.16 of September 30 closed the two ssl advisories plus the four Medium / Low items that had been queued since August — CVE-2026-19672, CVE-2026-15806, CVE-2026-17084 and CVE-2026-15310 — and bumped the bundled Expat to 2.8.5 and the bundled OpenSSL to 3.5.9 for the Windows, macOS, Android and iOS binaries; 3.13.16 additionally closed CVE-2026-82049 (8.4 High, the tarfile hard-link-to-symlink filter bypass, which never affected 3.14) and CVE-2026-87910 (5.7 Medium). The same set went out as source-only 3.12.15 the same day and 3.11.17 and 3.10.22 on October 1. Then came two more expedited rounds. On October 21, 3.15.1 and 3.14.9 closed both items this note had been carrying as open on the 3.14 line — CVE-2026-87910 and CVE-2026-12345 (3.14.9 only; 3.15.0 already had both) — bumped the bundled Expat to 2.9.0, fixed the Low-severity CVE-2024-3220 (mimetypes reading user-writable files on Windows), and shipped pip 26.2.2 with a certifi that drops the emSign roots after the eMudhra / emSign certificate-authority key compromise; 3.13.17 the same day was an exceptional security release with binary installers whose only security change was the pip bump. On October 24 the PSF published CVE-2026-115557 (CVSS 4.0 base 9.4 Critical from the PSF as CNA): ssl now carries a built-in denylist that rejects any certificate chain containing one of the compromised eMudhra intermediate CA keys, whatever the SSLContext configuration, as a last line of defense while root-store updates propagate (gh-160040). It shipped on October 25 in 3.15.2, 3.14.10, 3.13.18, 3.12.16 and 3.11.18, together with CVE-2026-114583 (6.9 Medium, published October 22; crafted link entries could get tarfile.tar_filter to write outside the extraction directory, the tar_filter counterpart of CVE-2026-7774; gh-160097); the source-only 3.13.18, 3.12.16 and 3.11.18 also picked up Expat 2.9.0, and 3.13.18 and 3.12.16 the CVE-2026-12345 fix. 3.10, end-of-life since October 1, got no build in either round. Still open as of this refresh (October 30, 2026), none of them High: CVE-2026-116566 (5.3 Medium, published October 29; socket.getaddrinfo() accepted embedded null bytes in host and port, silently truncating them; gh-160898) and CVE-2026-103995 (2.0 Low, published October 27; lenient parsing of Content-Length and chunk-size integers in http.client; gh-150751) are fixed on main only — the second is in the 3.16.0a1 pre-release — with no backport on the 3.15, 3.14 or 3.13 branches, and the PSF's records list every version below 3.16.0 as affected; and on the security-only 3.11 line, CVE-2026-12345 has no fix at all, so 3.11.18 still lacks it. The next scheduled maintenance releases are 3.15.3 and 3.14.11, both on December 1, 2026 per PEP 790 and PEP 745. No CPython advisory of High or worse is unfixed in a released build on any supported line. The bundled copy of Expat: every build cut since October 21 except 3.13.17 carries Expat 2.9.0 (October 5, 2026, still upstream's newest release), which fixes CVE-2026-102633 (CVSS 4.0 base 8.2 High and CVSS 3.1 base 5.9 Medium, both from VulnCheck as CNA; CWE-190), an integer overflow in expat_realloc() on 32-bit platforms affecting 2.7.2 through 2.8.5, and CVE-2026-77214 (8.3 High / 8.2 High; CWE-125), a heap over-read in XML_ParseBuffer that discloses adjacent heap memory to the calling application. 3.13.17 still bundles 2.8.5, and its Windows and macOS installers are, per the 3.13.18 release page, the last binary installers the 3.13 line gets — so those two Expat holes stay in the python.org 3.13 installers for good, while the source-only 3.13.18 has the fix. That exposure only reaches builds using CPython's vendored Expat — the default for a source build, and what the official python.org Windows and macOS installers ship — not builds configured with --with-system-expat, which is how most Linux distributions package Python. Confirm the latest point release against python.org/downloads.
Version
Python 3.14
3.x
Bugfix
EOL Oct 2030
Oct 7, 2025
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.
  • Python 3.14.8 (September 30, 2026) was an expedited security release and the eighth 3.14 maintenance release, with roughly 354 bugfixes, build improvements and documentation changes from 142 contributors since 3.14.7. It closed CVE-2026-19445 (CVSS 4.0 base 9.2 Critical from the Python Software Foundation as CNA; the ssl use-after-free when an sni_callback switches contexts) and CVE-2026-19553 (7.6 High; SSLContext.wrap_bio() skipping hostname verification), the four Medium / Low items queued since August (CVE-2026-19672, CVE-2026-15806, CVE-2026-17084, CVE-2026-15310), and bumped the bundled Expat to 2.8.5 and the bundled OpenSSL to 3.5.9. 3.14 was never affected by CVE-2026-82049, the tarfile hard-link-to-symlink hole fixed in 3.13.16 and the older lines: since 3.14.0b1, os.link() has followed symbolic links (gh-81793). The earlier 3.14.7 (August 5, 2026) had closed the two High advisories before it — CVE-2026-15308 (8.7 High, CPU denial-of-service in html.parser.HTMLParser) and CVE-2026-11940 (7.8 High, tarfile extraction-filter bypass) — plus the Low-severity CVE-2026-6879 and CVE-2026-18503. Notable correction (3.14.5): the incremental garbage collector shipped in 3.14.0–3.14.4 was reverted back to the generational GC from 3.13 due to memory-pressure reports in production; that release also rebundled Tcl/Tk 9.0.3 in the macOS installer. Since then, two expedited October releases: 3.14.9 (October 21, 2026) closed CVE-2026-87910 and CVE-2026-12345, moved the bundled Expat to 2.9.0 and pip to 26.2.2, and Python 3.14.10 (October 25, 2026), the latest point release as of this writing, added the ssl denylist for the compromised eMudhra CA keys (CVE-2026-115557, CVSS 4.0 base 9.4 Critical) and the tarfile.tar_filter fix for CVE-2026-114583 (6.9 Medium). What is still open on this line, and the state of the bundled Expat, is in the 3.15 row above, which carries the page's running security note. Next scheduled: 3.14.11 on December 1, 2026 per PEP 745.
  • Hugo van Kemenade as release manager, and again for 3.15. Confirm latest point release against python.org/downloads.
Version
Python 3.13
3.x
Security
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).
  • 3.13.16 (September 30, 2026) was the line's last regular bugfix release; 3.13 is now security-only, with source-only releases on an as-needed basis until October 2029 per PEP 719. One exception followed: 3.13.17 (October 21, 2026) was a special security release that — "exceptionally", in PEP 719's word — still came with binary installers, to ship pip 26.2.2 with the post-eMudhra certifi; the 3.13.18 release page names it the last 3.13 release with installers. 3.13.18 (October 25, 2026), source-only, is the latest: the ssl denylist for the compromised eMudhra CA keys (CVE-2026-115557, 9.4 Critical), CVE-2026-114583, CVE-2026-12345 and Expat 2.9.0 (details in the 3.15 row above). 3.13.16 had also closed CVE-2026-82049 (CVSS 4.0 base 8.4 High from the PSF as CNA) — the tarfile hard-link-to-symlink extraction-filter bypass that affected 3.13 and older but never 3.14 — and CVE-2026-87910 (5.7 Medium), along with the September 30 ssl advisories and the Expat 2.8.5 / OpenSSL 3.5.9 bumps it shares with 3.14.8 (details in the 3.15 row above).
  • 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
EOL
Oct 1, 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).
  • Reached end of life on October 1, 2026 with 3.10.22, a final source-only security release carrying the September 30 ssl advisories (CVE-2026-19445, CVE-2026-19553), the tarfile items and the Expat 2.8.5 bump from that round; the 3.10 series receives no further updates — it got no build in the October 25 round that every supported line received for CVE-2026-115557 (9.4 Critical, the ssl denylist for the compromised eMudhra CA keys). 3.10.11 had been the last release with binary installers.
  • Pablo Galindo as release manager.
Version
Python 3.9
3.x
EOL
Oct 31, 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
Mar 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, 2002
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.
  • Shipped six weeks before Python 2.0 (October 16, 2000), 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 and cmath; the ** power operator; name mangling for class-private attributes.
  • Complex numbers as a first-class numeric type — imaginary literals with a j suffix (3+4j), a complex() built-in, and a new cmath module mirroring math for complex arguments.
  • x ** y as an operator spelling of pow(x, y), and x[a, b, c] as shorthand for x[(a, b, c)].
  • Name mangling of __name attributes — a simple form of class-private variables.
  • The list() built-in, the long-awaited counterpart to tuple().
  • 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
lambda, map, filter, reduce, xrange; exec becomes a statement; double-quoted string literals.
  • Released from CWI (Centrum Wiskunde & Informatica) in Amsterdam, where Guido had been working since 1989.
  • Functional-programming primitives: the lambda keyword plus the map, filter and reduce built-ins — contributed by Amrit Prem, prompted by early users who came from Lisp and Scheme and kept re-implementing them by hand.
  • xrange(), the memory-compact counterpart to range(), arrived in the same batch.
  • exec became a statement rather than a built-in function, and string literals could now be written with double quotes as well as single.
  • A module could read its own name from __name__ — the change that makes the if __name__ == '__main__': idiom possible — and print began using a class's __str__ rather than its __repr__.
  • Classes, exception handling and the module system were not new here — all three were in 0.9.0 three years earlier.
  • Followed by 1.0.1 (Feb 1994), 1.1 (Oct 1994), 1.2 (Apr 1995) and 1.3 (Oct 1995) at CWI — 1.3's one headline change was keyword arguments in function calls.
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. /software/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 in June 2000 by PEP 1, written by Barry Warsaw and Jeremy Hylton; David Goodger and Alyssa Coghlan joined its author line through later revisions. The shape is borrowed from the IETF's RFC series. 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 Alyssa (Nick) Coghlan — the five top vote-getters recorded in PEP 8100. 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, and a substantial JIT overhaul in 3.15 (October 2026) — a new tracing frontend that records real execution paths, basic register allocation, and an LLVM 21 build-time dependency. The 3.15 What's New, re-benchmarked on September 25, 2026, reports a 7–8% geometric-mean gain over the fully optimized interpreter on x86-64 Linux and 11–12% over the tail-calling interpreter on AArch64 macOS (the rc2-era text had said 8–9% and 12–13%). Separately in 3.15, the official Windows 64-bit binaries switch to the tail-calling interpreter, reported at a 15–20% geometric-mean pyperformance gain over the switch-case interpreter they replace. The JIT is still opt-in at build time, and its future in CPython is now open. On June 5, 2026 the Steering Council asked for a Standards Track PEP making the case for the JIT, paused new JIT development on main until one is accepted, and set a six-month window: without an accepted PEP, the JIT code is to be removed from main and developed outside the repository. PEP 836 ("JIT Go Brrr", by Savannah Ostrowski, Ken Jin and Brandt Bucher) was that proposal; its authors withdrew it on October 19, 2026, saying they did not have the personal bandwidth to carry it forward. The council never ruled on it — it was never formally submitted — and as of October 30 no replacement PEP is on file. The work is publicly tracked in the faster-cpython/ideas GitHub repository.

Microsoft cancelled its sponsorship on May 15, 2025, laying off most of the team — Mark Shannon, Eric Snow and Irit Katriel among them — as part of a company-wide reduction. The project did not stop: within a day, core developers opened a community-stewardship thread on discuss.python.org and settled on an informal, non-decision-making performance working group in place of the weekly Microsoft-hosted syncs. The meetings moved to PSF-hosted infrastructure on a fortnightly cadence, and the benchmarking rigs are being migrated to the PSF (with a machine donated by Arm). Mark Shannon's own summary at the time was that it was "business as usual for the next few months" and that the project "always was driven by the community, not by Microsoft" — but the cadence is slower, and CPython's performance roadmap no longer has a funded full-time team behind it.

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. No PEP has yet scheduled that third phase. 3.15 (October 2026) delivered readiness work rather than the switch: PEP 803's abi3t, a stable ABI that lets one compiled C extension binary target free-threaded builds instead of requiring a separate build per Python version, and official macOS binaries that install free-threading support by default — while the free-threaded build is still not the default build. 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), PEP 649's deferred-evaluation rewrite in 3.14, and in 3.15 TypedDict with typed extra items (PEP 728), TypeForm (PEP 747) and disjoint bases (PEP 800). 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 arrived with IronPython 3.4 — an alpha in April 2021, then the first stable release, 3.4.0, in December 2022.
  • 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 ahead-of-time-compiled language for CPU / GPU / accelerator work, first previewed in 2023; Modular open-sourced the compiler in August 2026. The syntax is deliberately Python-familiar and extending existing Python packages is an explicit goal, but it is not a CPython implementation, and Modular's own roadmap now says Mojo may never become a full superset of Python.
  • 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. On March 19, 2026, Astral announced an agreement to join OpenAI as part of its Codex team, saying OpenAI would keep supporting uv, ruff and ty as open-source tools after the deal closes.

Packaging governance changed shape alongside the tooling. PEP 772 was accepted on April 16, 2026, creating a five-member elected Python Packaging Council with broad authority over the packaging interoperability standards and the Python Packaging User Guide. It formally replaces PEP 609's PyPA governance arrangement and absorbs the responsibilities of the PSF's Packaging Workgroup, ending the practice of routing packaging standards decisions through individual standing delegations from the Steering Council. The inaugural Packaging Council election runs alongside the 2026 PSF Board election; nominations ran from July 28 to August 11, 2026, and the PSF announced the slate on August 13, 2026 — 17 nominees for the five seats. Ballots went out on September 1 and voting closed at 14:00 UTC on September 15, 2026, after a voter-affirmation cutoff of August 25. The PSF published the results on September 17, 2026, on its blog rather than in the PEP, off 541 ballots. All five seats were filled at once, with the term length set by vote rank so that roughly half the council turns over each year: Brett Cannon and Pradyun Gedam took the two-year Cohort A seats, and Donald Stufft, Henry Schreiner and Ralf Gommers the one-year Cohort B seats. Packaging now has its own elected body for the first time, sitting alongside the Steering Council rather than under it.

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: The 2026-term Steering Council (elected December 2025): Pablo Galindo Salgado, Barry Warsaw, Thomas Wouters, Donghee Na, and Savannah Ostrowski. Earlier council members who shaped the modern era include Brett Cannon (importlib and the Python 3 import-system rewrite; core dev since 2003), Carol Willing (Project Jupyter), and Alyssa Coghlan (co-author of PEP 1 and PEP 8; runpy and the -m switch via PEP 338 / PEP 366; PEP 440 version specifiers). Ł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 / 3.15 release manager), Savannah Ostrowski (3.16 release manager; JIT contributor), Mark Shannon (Faster CPython lead through Microsoft's 2020–2025 sponsorship; 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.15.2

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.15
$ brew install python@3.14               # side-by-side, both kept

# Windows (winget)
> winget install Python.Python.3.14      # Python.Python.3.15 not yet in the winget catalog (Oct 2026)

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

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

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.15.2                     # default for this user
$ pyenv local 3.14.10                     # pin for the current directory tree

# uv (Astral): fast modern Python + venv + package manager
$ uv python install 3.15                  # 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.15
$ 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 October 2026.

Mungomash LLC · More data pages