Python 3.15 ist 140-mal schneller: 5 Python-Witze, die nicht mehr funktionieren

Python 3.15 ist 140-mal schneller. Das stimmt.

Du installierst die neue Version, startest ein Skript, das früher zehn Sekunden gebraucht hat, und schaust auf die Stoppuhr.

Neun Komma sieben.

Nein, niemand hat dich angelogen. Man erzählt sich über Python nur seit zwanzig Jahren denselben Witz: „Es ist langsam.“ Und diesmal hat Python so geantwortet, wie es das eben kann: präzise, ohne Tamtam und an ein paar Stellen gleich 140-fach.

Über die Jahre hat Python eine Menge Witze gesammelt. Es ist langsam. Seine Threads sind reine Deko. Bis ein Skript startet, hast du längst Kaffee gekocht. Fehlermeldungen lesen sich wie Rätsel. Umlaute und alles andere jenseits von reinem ASCII werden zu Zeichensalat, sobald du eine Datei unter Windows öffnest. Und das Prunkstück: „Python ist die zweitbeste Sprache für alles.“

Und jetzt das Schöne: In den letzten drei Jahren — mit Python 3.13, 3.14 und dem brandneuen 3.15 — hat die Sprache fast jeden davon systematisch abgearbeitet. Gehen wir die Liste durch.

Witz Nr. 1. „Python ist langsam“ → Geschwindigkeit von Python 3.15 und der JIT

Der Klassiker: Während Python noch in seiner Schleife steckt, hat das C-Programm kompiliert, ist fertig und längst im Feierabend.

Jetzt schauen wir, woher die 140-mal kommen. Ein unabhängiger pyperformance-Lauf — die Standard-Benchmark-Suite für CPython — hat Python 3.14.8 und 3.15.0 auf zwei Rechnern mit Windows 11 verglichen. Den Rekord holte der Test für Base32-Kodierung: rund 140-mal schneller auf einem Laptop mit Intel Core i3 und 135-mal auf einem AMD Ryzen 9.

Kurz gesagt: Base32 ist ein Verfahren, beliebige Bytes nur mit den Buchstaben A–Z und den Ziffern 2–7 aufzuschreiben, damit sie als reiner Text unterwegs sein können. Das begegnet dir öfter, als du denkst: Der geheime Schlüssel, den du als QR-Code in Google Authenticator scannst, ist in Base32 gespeichert.

Der Trick ist simpel. In 3.15 wurde Base32 in C neu geschrieben: Früher drehte es sich in einer Schleife aus reinem Python, jetzt läuft kompilierter Code. Das offizielle What's New in Python 3.15 spricht bescheiden von einer Beschleunigung um „zwei Größenordnungen“. Ascii85 und Base85, die unter anderem in PDFs stecken, wurden 57- bis 69-mal schneller. Base64 wurde 2- bis 3-mal schneller.

Dein Skript läuft natürlich nicht 140-mal schneller. Aber ein typischer Test aus derselben Suite wurde um 17–18 % schneller, am meisten legten JSON, reguläre Ausdrücke und Templating zu. Gratis. Du änderst keine einzige Zeile — du installierst einfach die neue Version. Für solche Gewinne optimieren Leute wochenlang ihren Code.

Und jetzt das große Ding: Der JIT ist endlich angesprungen.

Kurz gesagt: Ein JIT-Compiler (Just-In-Time) ist der Teil des Interpreters, der während der Laufzeit deines Programms den Code findet, der am häufigsten ausgeführt wird, und ihn in Maschinenbefehle übersetzt. Ein normaler Interpreter arbeitet den Bytecode jedes Mal aufs Neue ab. Der JIT erledigt diese Arbeit einmal und führt danach nur noch das Ergebnis aus.

In Python 3.13 war der JIT eher eine Anzahlung auf die Zukunft. In 3.15 wurde er gründlich überarbeitet und bringt laut den offiziellen Zahlen +7–8 % unter Linux und +11–12 % auf Macs mit Apple Silicon. Miguel Grinberg, Autor des bekannten Flask Mega-Tutorial, lässt bei jeder Version dieselben Tests in reinem Python laufen — nach seinen Messungen machte der JIT den Code 1,20–1,28-fach schneller. Der JIT ist noch experimentell und wird von Hand über die Variable PYTHON_JIT=1 eingeschaltet, aber die Richtung ist klar.

Hat Python C eingeholt? Nein, und das will es auch gar nicht. Aber der Witz mit dem „langsam“ fängt an zu husten.

Witz Nr. 2. „Threads in Python sind reine Deko“ → Python ohne GIL

Du hast acht Kerne. Du startest acht Threads. Python läuft auf einem Kern und tut so, als wäre das von Anfang an der Plan gewesen.

Schuld ist der GIL. Kurz gesagt: Der GIL (Global Interpreter Lock) ist eine Sperre, durch die normales Python zu jedem Zeitpunkt nur in einem einzigen Thread Code ausführt, egal wie viele Kerne deine CPU hat. Zwanzig Jahre lang war er das Standardargument in jeder Debatte „Python gegen den Rest der Welt“.

So lief es ab. Python 3.13 brachte einen experimentellen Build, in dem sich der GIL abschalten lässt. Free-threaded Python, also Python ohne GIL, ist ein separater Build des Interpreters, in dem Threads wirklich parallel auf verschiedenen Kernen laufen. In 3.14 wurde er offiziell unterstützt, und sein Preis in Single-Thread-Code sank auf 5–10 %. Und jetzt der Lohn: In Grinbergs Tests unter 3.15 berechnete der free-threaded Build Fibonacci-Zahlen auf vier Threads mehr als viermal so schnell wie der normale.

Mehr als viermal so schnell. Einfach, weil die Threads endlich parallel laufen.

Ein Haken: Es ist ein separater Interpreter. Die offiziellen Installer von python.org für Windows und macOS können ihn neben dem normalen installieren (unter macOS wird er in 3.15 standardmäßig mitinstalliert), aber der einfache Befehl python startet weiterhin den Build mit GIL. Was bei dir läuft, prüfst du mit einer Zeile:

import sys
print(sys._is_gil_enabled())   # False heißt: der GIL ist aus

Der zwanzig Jahre alte Witz erlebt seine letzten Releases.

Witz Nr. 3. „Bis ein Skript startet, kannst du Kaffee kochen“ → lazy imports

Ein Kommandozeilen-Tool, das nur --help anzeigen soll, denkt ein paar Sekunden nach. Weil es beim Start brav pandas, requests und zwanzig weitere Module lädt, die --help überhaupt nicht braucht.

Python 3.15 bringt lazy imports. Kurz gesagt: Ein lazy import ist ein Import, bei dem das Modul nicht in der import-Zeile geladen wird, sondern erst dann, wenn du es zum ersten Mal wirklich benutzt. Eingeschaltet wird das mit dem Schlüsselwort lazy:

lazy import json
lazy from pathlib import Path

print("Starte...")                   # json und pathlib sind noch nicht geladen

data = json.loads('{"ok": true}')    # json wird erst jetzt geladen

Ein lazy import ist wie ein Gast, der unten im Auto wartet und erst hochkommt, wenn du nach ihm rufst. Ruft keiner, muss auch keiner ein Gedeck auflegen.

Laut den Autoren von PEP 810 können Kommandozeilen-Tools 50–70 % schneller starten, und der Speicherverbrauch in realen Workloads sinkt um 30–40 %. Das ist kein Laborspielzeug: Meta setzt lazy imports schon lange auf den Servern von Instagram ein, und einige der Autoren des Vorschlags arbeiten genau dort.

Deine Kaffeepausen werden bald deutlich kürzer.

Witz Nr. 4. „Fehlermeldungen in Python sind Rätsel“ → klügere Fehlermeldungen

Zwanzig Jahre lang lief es immer gleich: Du bekommst einen Fehler, kopierst ihn in die Suchmaschine, liest drei Antworten auf Stack Overflow und probierst die vierte. Die letzten drei Python-Releases fanden, dass so niemand leben sollte.

Deine Datei heißt random.py und enthält import random? Früher endete das mit einem mysteriösen „module has no attribute randint“ und einer halben Stunde Leiden. Seit 3.13 sagt Python es dir direkt: Deine Datei heißt genauso wie ein Modul der Standardbibliothek, benenn sie um.

Ein Tippfehler in whille True:? Seit 3.14 fragt Python: „Did you mean 'while'?“

Und 3.15 ist regelrecht scharfsinnig geworden:

AttributeError: 'list' object has no attribute 'push'. Did you mean '.append'?
AttributeError: 'dict' object has no attribute 'put'. Use d[k] = v.

Die erste Zeile ist ein persönlicher Gruß an alle, die von JavaScript kommen. Die zweite an alle, die von Java kommen. Der Interpreter erkennt dich am Akzent.

Und ein besonderes Dankeschön an 3.13 für die neue REPL: farbige Fehler, mehrzeiliges Editieren, und zum Beenden reicht jetzt einfach exit. Ohne Klammern. Eine ganze Generation, die direkt nach „wie beende ich Vim“ auch „wie beende ich Python“ gegoogelt hat, kann endlich durchatmen.

Witz Nr. 5. „Umlaute unter Windows? Viel Glück“ → UTF-8 als Standard

Wenn du jemals unter Windows Python geschrieben hast, kennst du diese Zeile nur zu gut:

UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 12

Vor 3.15 hat open("file.txt") ohne explizite Kodierung die Kodierung des Systems benutzt, und unter Windows ist das meist nicht UTF-8. Ein typografisches Anführungszeichen aus Google Docs reichte, damit das Skript abstürzte, und Müller wurde still und leise zu Müller. In 3.15 ist UTF-8 überall der Standard. Eine der häufigsten Einsteigerfragen verschwindet einfach.

Wenn dein Code auch auf älteren Versionen laufen muss, schreib encoding="utf-8" trotzdem besser explizit hin. „Explicit is better than implicit“ stammt aus dem Zen of Python, und mit dem Zen diskutiert man nicht.

Bonus: frozendict, t-strings und andere kleine Gewinne

Das waren nie Witze, aber sie sind zu gut, um sie wegzulassen.

frozendict (3.15, PEP 814). frozendict ist ein unveränderliches Dictionary: Du erzeugst es einmal und kannst es danach nicht mehr ändern. Die Liste hat einen unveränderlichen Verwandten — das Tupel; das Set hat frozenset. Das Dictionary hat über dreißig Jahre auf sein eigenes gewartet:

config = frozendict(host="localhost", port=8000)
config["port"] = 9000   # TypeError: ändern geht nicht

Unveränderlichkeit wurde früher per Kommentar # NICHT ANFASSEN!!! durchgesetzt. Jetzt schützt der Interpreter selbst deine Einstellungen — auch vor dir um 3 Uhr nachts.

Entpacken in List Comprehensions (3.15). Eine Liste von Listen wird flach, ohne die doppelte Schleife, die die Hälfte aller Leute zweimal lesen muss:

flat = [*L for L in [[1, 2], [3, 4], [5]]]   # [1, 2, 3, 4, 5]

except ohne Klammern (3.14). except TimeoutError, ConnectionRefusedError: — eine Kleinigkeit, aber eine schöne.

t-strings (3.14, PEP 750). t-strings sind Verwandte der f-strings, die statt eines fertigen Strings ein Template zurückgeben. Bibliotheken können die eingesetzten Werte sicher verarbeiten, bevor daraus eine SQL-Injection wird.

Der Profiler Tachyon (3.15). Er hängt sich an ein bereits laufendes Programm, zeigt, wo es langsam ist, und bremst es dabei kaum aus. Anders als das alte cProfile, das wie ein Thermometer war, von dem man Fieber bekommt. Start mit fertigem Flame Graph:

python -m profiling.sampling run --flamegraph -o profile.html script.py

Und für einen Prozess, der schon läuft — python -m profiling.sampling attach plus die Prozess-ID (dafür brauchst du Admin-Rechte).

Warum das wichtiger ist als 140-mal

Zähl die drei Releases zusammen, und du bekommst ein Bild, das hinter den Benchmark-Schlagzeilen leicht untergeht.

Python ist schon jetzt die Hauptsprache für KI und Datenarbeit. Man liebte es, weil es sich schnell schreibt, und nahm hin, dass es langsam läuft. Jetzt streicht es systematisch die zweite Hälfte dieses Satzes: der JIT, Threads ohne GIL, schneller Start, verständliche Fehlermeldungen.

Wenn du Python lernst, ist das die beste Nachricht, die du kriegen kannst. Du investierst in eine Sprache, die jedes Jahr stärker wird. Der Code, den du heute in Übungsaufgaben schreibst, kann morgen in einem Multithreading-Service mit JIT laufen — und für die Geschwindigkeit musst du nicht die Sprache wechseln.

Lern es nur so, wie es heute ist. KI-Assistenten sind mit Bergen von Code groß geworden, der vor 3.15 geschrieben wurde: kein lazy import, kein frozendict und jede Menge open()-Aufrufe ohne Kodierung. Das Modell schreibt Code so, „wie man es früher gemacht hat“. Zu wissen, wie es heute geht, ist dein Vorsprung.

Und ja, die neuen Features lernst du an einem Abend. Um aber zu verstehen, warum das in C neu geschriebene Base32 140-mal schneller wurde und dein Skript nicht, brauchst du die Grundlagen: wie der Interpreter funktioniert, was Bytecode ist und warum eine Schleife in reinem Python langsamer ist als eine Schleife in C. In welcher Reihenfolge du sie lernst, haben wir in unserer Python-Entwickler-Roadmap 2026 aufgeschrieben. Versionen ändern sich. Grundlagen zahlen sich mit Zinseszins aus.

Spickzettel: Neuerungen in Python 3.13, 3.14 und 3.15

FAQ zu Python 3.15

Ist Python 3.15 wirklich 140-mal schneller?

Nur in einem Test — der Base32-Kodierung, die von reinem Python nach C umgeschrieben wurde. Ein typischer Test aus der pyperformance-Suite wurde um 17–18 % schneller, und wenn man die Kodierungstests weglässt, liegt der durchschnittliche Gewinn bei etwa dem 1,2-Fachen. Dein unveränderter Code wird höchstwahrscheinlich um Prozente schneller, nicht um ein Vielfaches.

Wann ist Python 3.15 erschienen?

Am 9. Oktober 2026. Neue Python-Versionen erscheinen einmal im Jahr, jeweils im Oktober.

Wie schalte ich den JIT in Python 3.15 ein?

Mit einer Umgebungsvariable vor dem Start: PYTHON_JIT=1 python script.py. Die offiziellen Builds für Windows und macOS enthalten den JIT bereits, aber er ist ausgeschaltet. Er ist noch experimentell und bringt +7–8 % unter Linux x86-64 und +11–12 % auf Macs mit Apple Silicon.

Wie installiere ich Python ohne GIL?

Die offiziellen Installer von python.org für Windows und macOS können es neben der normalen Version installieren, unter macOS wird es in 3.15 standardmäßig mitinstalliert. Für Linux und den Build aus dem Quellcode gibt es eine Anleitung in der Dokumentation. Zum Prüfen führst du sys._is_gil_enabled() aus: Gibt es False zurück, laufen deine Threads parallel.

Lohnt sich das Upgrade auf Python 3.15?

• Du lernst Python — ja, installier 3.15. Die neuen Fehlerhinweise sparen dir mehr als einen Abend.
• Du arbeitest an einem Nebenprojekt — nur zu, prüf aber vorher, ob die Bibliotheken, die du brauchst, 3.15 schon unterstützen.
• Du betreibst etwas in Produktion — warte auf Builds deiner wichtigsten Abhängigkeiten und die ersten Bugfix-Releases. Den JIT in Produktion vorerst nicht einschalten.

Der letzte Witz

Nur ein Witz von der Liste steht noch: „Python ist die zweitbeste Sprache für alles.“

Aber mit jedem Release wird das Wort „zweitbeste“ ein bisschen leiser.

Witze über Python veralten schneller als Python selbst. Ein guter Moment, es zu lernen.