fastcore v2: Was der Bruch mit alten APIs bedeutet
FastCore ist ein KI-Inferenz-Toolkit, das sich auf zuverlässige Laufzeitorchestrierung, Tool-Integrationen und schnelle lokale Experimente konzentriert.
Auf einen Blick
- Was ist das?
- Ein Überblick über AnswerDotAI/fastcore v2: welche APIs im Juli 2026 entfernt oder verschoben wurden, was L und die star-Adapter leisten, und wo das README Lücken lässt.
- Für wen ist es gedacht?
- Geeignet ist fastcore für Python-Projekte, in denen Boilerplate in __init__, Listenoperationen und Async-Helfer täglich wiederkehren und die auf Python 3.11 oder neuer laufen. Wer HTTP-Aufrufe über urlsend oder urlrequest von fastcore.net gebaut hat, sollte vor dem Umstieg prüfen, ob ein Wechsel auf requests oder httpx weniger Aufwand bedeutet als das Pin von fastcore<2.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Jupyter Notebook, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was fastcore v2 im Juli 2026 entfernt hat
Der Juli 2026 brachte fastcore v2, und dieses Release räumt auf: APIs, für die es inzwischen bessere Alternativen gab, wurden entfernt oder verschoben. Wer `from fastcore.utils import *` oder `fastcore.all` nutzt, merkt laut README davon meist nichts. Wer dagegen einzelne Namen importiert, muss handeln.
`Param` ist aus `fastcore.script` verschwunden. Statt seiner sollen einfache Typannotationen mit docments dienen oder `typing.Annotated[type, "help"]`, auf Wunsch ergänzt um ein dict mit argparse-Argumenten für die Fälle, in denen die Kurzform nicht ausreicht. Damit verschiebt sich die Definition einer Kommandozeile vom Dekorator hin zur Signatur.
Ebenso deutlich ist der Schnitt bei `parallel_gen`: Die Funktion gibt es nicht mehr, an ihre Stelle tritt das initializer-Muster des stdlib-ProcessPoolExecutor, für das fastai mit `parallel_tokenize` ein Rezept zeigt. Dazu kommt eine harte Voraussetzung, die über reine API-Fragen hinausgeht: Python 3.11 oder neuer. Das README nennt für Bestandscode einen Ausweg, nämlich `fastcore<2` zu fixieren.
L, star und rstar: Listenoperationen bei fastcore
Die Klasse `L` ist der sichtbarste Teil von fastcore und laut README ein Drop-in-Ersatz für `list`. Das Beispiel im README zeigt, was das praktisch heißt: `x = L(1,2,3,4)` lässt sich mit einer Sammlung indizieren, `x[[0,3]]` ergibt `[1,4]`, `x.map(lambda o:o*2)` verdoppelt jedes Element, `x.filter(lambda o:o>2)` siebt, und nach `x += [5]` liefert `x.unique()` die fünf verschiedenen Werte.
Erweiterte Indizierung und Method Chaining erwähnt das README ausdrücklich, zur Implementierung und zu Laufzeitunterschieden gegenüber einer gewöhnlichen Liste schweigt es. Solche Angaben fehlen auch in der verlinkten API-Liste, die nur Namen aufführt.
Bei v2 ändert sich hier am meisten. `starmap`, `starfilter` und die übrigen `star*`- und `rstar*`-Methoden sind weg. An ihre Stelle treten die Funktionsadapter `star` und `rstar`, die sich mit jeder L-Methode kombinieren lassen, etwa `t.map(star(f))`. Wer `spread` verwendet hat, nimmt jetzt `star`; aus `dspread` wurde `dstar`. Der Gewinn liegt in der Kombinierbarkeit, der Preis ist eine Anpassung jeder betroffenen Zeile.
@patch, store_attr und delegates im fastcore-Alltag
Zwei Werkzeuge zielen auf Schreibarbeit, die in größeren Python-Projekten ständig wiederkehrt. `store_attr()` soll in `__init__` mehrere Attribute in einem Aufruf aus den Argumenten setzen und damit die Kette einzelner Zuweisungen ersetzen. Der Dekorator `delegates` verfolgt das Gegenteil von Bequemlichkeit um jeden Preis: Er ersetzt `**kwargs` in einer Signatur durch ausformulierte Parameter, was Autovervollständigung und generierte Dokumentation verbessern soll. `docments` ergänzt das um Parameterdokumentation direkt im Quelltext.
`@patch` ist der radikalste der drei, weil er Methoden an bestehende Klassen hängt, eingebaute Typen eingeschlossen, ohne dass eine Unterklasse nötig wird. Für keines dieser Werkzeuge zeigt das README ein vollständiges Beispiel. Gerade bei `@patch` wiegt das schwer: Ob so hinzugefügte Methoden beim Pickling oder in Prozess-Pools erhalten bleiben, ist in der Dokumentation nicht angegeben.
Wer Attribute lieber deklarativ erzeugt, findet in `attrs` eine Alternative. `attrs` generiert mit `@define` und Annotationen eine `__init__`, verändert aber keine fremden Klassen und bringt keine eigene Listenklasse mit.
fastcore.aio: run_sync, mapa und acache unter einem Dach
Mit v2 bekommen die asynchronen Helfer ein eigenes Modul, `fastcore.aio`. Aus `net` wandern `run_sync`, `iter_sync` und `ctx_sync` dorthin, aus `xtras` folgen `maybe_await`, `then`, `mapa`, `acache`, `reawaitable` und `is_async_callable` sowie die übrigen Async-Werkzeuge. Auch `Config` und die Funktionen für Konfigurationsdateien wechseln die Ebene, von `foundation` nach `xtras`.
`fastcore.net` verliert seine Request-Builder `urlrequest`, `urlsend`, `do_request` und `urlcheck`; `clean_type_str` ist gestrichen. Für Projekte, die HTTP-Aufrufe über `urlsend` gebaut haben, ist das ein Eingriff mit Folgen, denn das README benennt keinen Ersatz innerhalb von fastcore. Bleiben zwei Wege: auf `requests` oder `httpx` ausweichen, oder bei `fastcore<2` bleiben.
`timed_cache` bleibt erhalten und erweitert `lru_cache` um eine zeitbasierte Ablauffrist. Für Zwischenspeicher, deren Inhalt nach Minuten veraltet, ist das die Alternative zum manuellen Invalidieren.
Installation von fastcore: conda, pip und Python 3.11
Die Installation ist im README in drei Varianten beschrieben. Für Anaconda lautet der Weg `conda install fastcore -c fastai`, mit pip genügt `pip install fastcore`. Wer am Quelltext arbeiten will, klont das Repository und setzt `pip install -e ".[dev]"`, wodurch die Entwicklerabhängigkeiten mitkommen.
Getestet wird nach README-Angaben auf Ubuntu, macOS und Windows, konkret auf den Läufern mit dem Suffix `-latest`, wie sie die GitHub-Dokumentation zu gehosteten Runnern aufführt. Eine Liste geprüfter Python-Versionen jenseits der Untergrenze 3.11 fehlt.
Für einen belastbaren Eindruck taugt ein frisches Virtualenv mit `pip install "fastcore==2.2.16"` und anschließend die Probe, ob `from fastcore.aio import run_sync, mapa, acache` fehlerfrei durchläuft. Genau diese drei Namen sind in v2 umgezogen. Schlägt der Import fehl, liegt ein Restbestand älterer Importpfade im eigenen Code vor, kein Fehler der Installation. Wer Skripte über `fastcore.script` baut, prüft zusätzlich, ob die eigene Annotation mit `typing.Annotated` die erwartete Hilfezeile erzeugt.
Apache-2.0 und die fastcore-Kadenz von 2.2.14 bis 2.2.16
Das Repository steht unter Apache-2.0. Der Lizenztext gewährt eine dauerhafte, weltweite, nicht ausschließliche und gebührenfreie Urheberrechtslizenz zum Vervielfältigen, zum Erstellen abgeleiteter Werke und zur Weiterverbreitung, ergänzt um eine Patentlizenz, die erlischt, sobald der Lizenznehmer selbst Patentklagen gegen das Werk erhebt. Eine Garantie oder Supportzusage ist damit nicht verbunden.
Konkret heißt das für den Einsatz: Einbetten in kommerzielle Produkte ist erlaubt, solange die Bedingungen der Lizenz eingehalten werden, eine Haftung für Ausfälle trägt niemand. Für Projekte mit Freigabeprozess ist das eine überschaubare Prüfung, weil Apache-2.0 zu den weit verbreiteten Lizenzen gehört.
Die Release-Historie zeigt ein hohes Tempo. Version 2.2.14 erschien am 23. August 2026, 2.2.15 am 25. August und 2.2.16 am 26. August 2026. Drei Veröffentlichungen in vier Tagen sprechen für aktive Pflege, bedeuten aber auch, dass das Festschreiben einer Version hier Pflicht statt Kür ist. Das Repository weist 1.105 Sterne, 294 Forks und 35 offene Issues auf, der letzte Push datiert auf den 26. August 2026.
Redaktionelles Fazit
Geeignet ist fastcore für Python-Projekte, in denen Boilerplate in __init__, Listenoperationen und Async-Helfer täglich wiederkehren und die auf Python 3.11 oder neuer laufen. Wer HTTP-Aufrufe über urlsend oder urlrequest von fastcore.net gebaut hat, sollte vor dem Umstieg prüfen, ob ein Wechsel auf requests oder httpx weniger Aufwand bedeutet als das Pin von fastcore<2. Als erstes zu klären ist, ob die eigenen Importpfade noch stimmen: from fastcore.aio import run_sync, mapa, acache auf Version 2.2.16 muss fehlerfrei durchlaufen.
Community-Notizen