💻 computer science

Stdlib or Third-Party? Empirical Performance and Correctness of LLM-Assisted Zero-Dependency Python Libraries

Dit artikel presenteert "zerodep", een open-source collectie van door LLM's ondersteunde, single-file Python-herimplementaties van de standaardbibliotheek van populaire modules van derden, die aantonen dat terwijl taken met zware C-uitbreidingen een prestatiefiguur blijven, alternatieven uitsluitend met de standaardbibliotheek vaak vergelijkbare snelheid bereiken of zelfs aanzienlijke snelheidswinst behalen door architecturale overhead te elimineren, waarmee de haalbaarheid van afhankelijkheid-vrije software-engineering met hoge correctheid wordt gevalideerd.

Oorspronkelijke auteurs: Peng Ding, Rick Stevens

Gepubliceerd 2026-05-21

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Peng Ding, Rick Stevens

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een huis bouwt. In de wereld van Python-programmeren is de "Standard Library" (stdlib) als een hoogwaardige, voorverpakte gereedschapskist die gratis bij elke Python-installatie wordt geleverd. Hij bevat hamers, schroevendraaiers en zagen. Voor specifieke, geavanceerde taken kopen programmeurs echter vaak "Third-Party Libraries". Dit zijn als gespecialiseerde, merkgebonden gereedschapssets die je van internet downloadt. Ze zijn krachtig, maar hebben een nadeel: ze vereisen vaak dat je andere gereedschappen koopt om ze te gebruiken (afhankelijkheden), ze kunnen kapotgaan als het merk zijn regels wijzigt, en ze kunnen beveiligingsrisico's introduceren als het merk wordt gecompromitteerd.

Dit paper, getiteld "Stdlib or Third-Party?", stelt een eenvoudige maar diepzinnige vraag: Hoeveel van die geavanceerde, gespecialiseerde gereedschapsset kunnen we eigenlijk herbouwen met alleen de gratis, basisgereedschappen die we al hebben?

Om dit te beantwoorden, creëerden de auteurs een project genaamd zerodep. Denk aan zerodep als een "DIW-werkplaats" waar ze 44 populaire, complexe Python-tools namen en probeerden deze vanaf nul te herbouwen met alleen de standaardgereedschapskist. Ze deden dit niet alleen; ze gebruikten een AI-assistent (een LLM) om de code te schrijven, maar ze hielden de AI aan een zeer strakke leiband:

Geen nieuwe gereedschappen toegestaan: Je mag niets importeren dat niet al in de standaard Python-kist zit.
Slechts één bestand: De hele tool moet op één vel papier passen (één enkel .py-bestand).
Direct vervangbaar: Het moet precies werken als de originele tool, zodat je ze kunt verwisselen zonder je huis te breken.
Bewijs van werk: De creatie van de AI moet een strenge test doorstaan tegen het origineel om te bewijzen dat het correct werkt.

De Drie Belangrijkste Bevindingen

De onderzoekers testten deze 44 herbouwde tools tegen de originalen en vonden drie distincte "zones" van prestaties:

1. De "Lightweight Win"-zone (De AI deed het hier geweldig)

Voor veel algemene taken waren de originele third-party tools eigenlijk over-engineerd. Ze waren als een Zwitsers zakmes met 50 gadgets, terwijl je alleen een schroevendraaier nodig had. De AI, gedwongen om alleen de basisgereedschappen te gebruiken, bouwde een eenvoudige, gestroomlijnde schroevendraaier die eigenlijk sneller was.

De Analogie: Stel je een restaurant voor dat een complex, meer-gangenmenu serveert alleen om je een glas water te geven. De zerodep-versie is gewoon een glas water. Het is veel sneller om te krijgen.
Het Resultaat: In categorieën zoals het lezen van configuratiebestanden, het afhandelen van retries (opnieuw proberen als iets mislukt) en het parseren van tekst, waren de door de AI gebouwde tools vaak 5 tot 115 keer sneller dan de originalen, omdat ze alle onnodige "ballast" hadden weggelaten.

2. De "Parity"-zone (Voldoende goed)

Voor ongeveer twee derde van de tools waren de door de AI gebouwde versies net zo goed als de originalen. Ze waren misschien iets trager of iets sneller, maar ze lagen binnen een "veilige marge" (minder dan 2x verschil).

De Analogie: Het is als het rijden in een betrouwbare sedan versus een luxe sportauto. De sportauto (third-party) is misschien iets sneller, maar de sedan (stdlib) brengt je op bijna dezelfde tijd naar dezelfde bestemming, zonder dat je een speciale monteur nodig hebt om hem te repareren.
Het Resultaat: Voor taken zoals basisnetwerkcommunicatie of datavalidatie is de standaardlibrary perfect in staat het werk te doen zonder extra downloads.

3. De "Hard Wall"-zone (De C-extension-afgrond)

Er was één plek waar de AI en de standaardlibrary op een muur botsten: zware wiskunde en low-level verwerking.

De Analogie: Stel je voor dat je een enorme muurschildering probeert te schilderen. De third-party tools gebruiken een team van professionele schilders met industriële spuitpistolen (gecompileerde C- of Rust-code). De AI, beperkt tot de standaardlibrary, is gedwongen een klein penseel en een emmer verf te gebruiken. Hoe hard de AI ook probeert, het kan niet concurreren met de snelheid van de industriële spuitpistool.
Het Resultaat: Voor dingen zoals het verwerken van afbeeldingen (pixels), zware cryptografie (encryptie) of complexe binaire data was de standaardlibrary aanzienlijk trager (soms 300x trager).
De Omweg: De auteurs vonden een slimme truc: in plaats van de muurschildering zelf te schilderen, bouwden ze een kleine deur in de muur en vroegen ze de professionele schilders (de ingebouwde C-bibliotheken van het systeem) om binnen te komen en het zware werk te doen. Deze "subprocess"-truc stelde hen in staat de snelheid van de professionals te krijgen zonder nieuwe tools te hoeven downloaden.

De Rol van de AI (LLM)

Het paper keek ook naar hoe goed de AI het werk deed.

Eenvoudige Taken: Voor kleine, simpele tools was de AI een tovenaar. Het kon een werkende versie in één of twee pogingen schrijven.
Complexe Taken: Voor enorme, ingewikkelde systemen (zoals een volledige webserver) raakte de AI in de war. Het had een menselijk architect nodig om eerst de blauwdrukken te tekenen. Zodra de mens de structuur had vastgesteld, kon de AI de details invullen.
Het Veiligheidsnet: Het belangrijkste onderdeel van het proces was de "Correctness Test". De AI zou raden, de test zou zeggen "Fout", en de AI zou het opnieuw proberen. Deze lus zorgde ervoor dat het eindproduct daadwerkelijk werkte, en voorkwam dat de AI "hallucineerde" (verzon) nep-tools die niet bestaan.

De Conclusie

Het paper concludeert dat voor de meeste alledaagse programmeertaken je de geavanceerde third-party tools niet nodig hebt. Je kunt vaak een snellere, veiligere en lichtere versie bouwen met alleen de standaardlibrary, vooral met de hulp van een AI.

Echter, als je zwaar werk doet zoals afbeeldingsverwerking of hoge-snelheid encryptie, bereikt de standaardlibrary een snelheidslimiet die alleen gespecialiseerde, gecompileerde code kan doorbreken. In die gevallen heb je ofwel de third-party tools nodig, of een slimme omweg om kracht te lenen van de native code van het systeem.

Kortom: Voor 2/3 van je programmeerbehoeften is de "gratis gereedschapskist" alles wat je nodig hebt, en het is misschien zelfs sneller. Voor de andere 1/3 heb je nog steeds de gespecialiseerde uitrusting nodig, maar je weet nu precies waar de lijn wordt getrokken.

Technische Samenvatting: Empirische Prestaties en Correctheid van door LLM's ondersteunde Zero-Dependency Python-bibliotheken

Probleemstelling

Het Python-pakkettenecosysteem, hoewel overvloedig, introduceert aanzienlijke overhead door transitive afhankelijkheden, risico's in de supply chain en wrijving bij implementatie. Empirische studies geven aan dat een enkele gedeclareerde afhankelijkheid vaak een mediaan van 8–10 extra transitive pakketten activeert, waarbij meer dan 70% van de code in een afhankelijkheidssluiting nooit wordt uitgevoerd. Bovendien genereren door Large Language Models (LLM's) gegenereerde code vaak hallucinaties van niet-bestaande pakketnamen, wat latente beveiligingskwetsbaarheden creëert.

Hoewel ontwikkelaars vaak terugvallen op "copy-paste" hergebruik voor kleine hulpprogramma's om afhankelijkheden te vermijden, mist deze aanpak systematische correctheidsgaranties, versiebeheer en prestatiebaselines. De centrale onderzoeksvraag is: In welke mate kunnen populaire derde-partij utility-bibliotheken worden vervangen door single-file, alleen-standaardbibliotheek (stdlib) implementaties zonder correctheid of prestaties te offeren, en kunnen LLM's dergelijke code effectief genereren onder strikte beperkingen?

Methodologie

De auteurs introduceren zerodep, een gecureerde testomgeving van 44 single-file Python-modules. Elke module is een herimplementatie van een populaire derde-partij bibliotheek (bijv. PyYAML, httpx, Pillow, tenacity) met uitsluitend gebruik van de Python-standaardbibliotheek.

Ontwerpbeginselen

Zero Dependencies: Geen externe imports; alle functionaliteit moet vertrouwen op de Python-standaardbibliotheek.
Single File: Elke module is opgenomen in één enkel .py-bestand om auditing en embedding te vereenvoudigen.
API-compatibiliteit: Modules bieden drop-in API-compatibiliteit met hun referentiebibliotheken.
Validatie van Correctheid: Elke module wordt gekoppeld aan een testsuite die het gedrag vergelijkt met de referentiebibliotheek met identieke invoer.

Ontwikkelingsworkflow

De modules werden ontwikkeld via een iteratief mens-LLM samenwerkingsproces:

Specificatie: Definieren van de API-sfeer en intentionele vereenvoudigingen.
Generatie: LLM's (voornamelijk Claude en o-serie modellen) genereren initiële implementaties onder strikte beperkingen.
Oracle-validatie: Gegenereerde code wordt getest tegen de referentiebibliotheek; fouten worden teruggekoppeld aan de LLM voor verfijning.
Prestatiebeoordeling: Benchmarks worden uitgevoerd om regressies te identificeren, waarbij menselijke begeleiding wordt gebruikt om kritieke paden te optimaliseren (bijv. het selecteren van specifieke stdlib-primitieven).

Evaluatieomvang

De studie bestrijkt 44 modules over 12 categorieën (Netwerk, Protocol, Serialisatie, Tekst, Crypto, enz.) en drie complexiteitsniveaus (Eenvoudig, Gemiddeld, Subsysteem). De evaluatie richt zich op:

Correctheid: Gedrags-equivalentie tegenover referentiebibliotheken over honderden testvectoren.
Prestaties: Benchmarken van uitvoeringstijd tegenover referentiebibliotheken, waarbij "pariteit" wordt gedefinieerd als een snelheidsratio binnen een factor 2 ( $0.5 \le r \le 2.0$ ).

Belangrijkste Bijdragen

De zerodep Testomgeving: Een versiebeheerde, gebenchmarkde collectie van 44 stdlib-only modules, elk met een correctheidstestsuite en prestatiebaseline.
Empirische Correctheidsevaluatie: Een systematische analyse van waar gedrags-equivalentie geldt en waar intentionele vereenvoudigingen worden toegepast.
Prestatiekarakterisering: Identificatie van drie distincte prestatie-regimes:
- Pariteit: Prestaties binnen 2× van de referentie.
- Architecturale Win: Significante snelheidswinsten (5–115×) door de eliminatie van overhead van de referentiebibliotheek.
- C-Extension Cliff: Ernstige prestatiedegradatie wanneer de referentie vertrouwt op gecompileerde C/Rust-extensies.
Analyse van door LLM's ondersteunde ontwikkeling: Observaties over de effectiviteit van LLM's over complexiteitsniveaus, met benadrukking van de noodzaak van menselijke architecturale begeleiding voor complexe subsystemen.

Resultaten

Correctheid

Alle 44 modules slagen hun correctheidstests. De studie vond uit dat gedragsdivergentie vaak subtiel is (bijv. YAML null-representaties, JSON-commentaar-edgecases) in plaats van API-mismatches. Modules met intentionele API-vereenvoudigingen (bijv. het weglaten van zelden gebruikte validators) documenteren deze omissies expliciet.

Prestatieregimes

Architecturale Winsten (Sneller): 19 modules zijn consequent sneller dan hun referenties, vaak met ordes van grootte.
- Voorbeelden: jsonc is 75–115× sneller dan commentjson (het vermijden van eval); httpclient is 18–32× sneller dan httpx (het verwijderen van middleware-lagen); yaml is 6–7× sneller dan het pure-Python-pad van PyYAML.
- Oorzaak: Veel derde-partij bibliotheken dragen architecturale overhead (pluginsystemen, intermediaire representaties) die gerichte stdlib-implementaties vermijden.
Pariteit: 11 modules bereiken prestatiepariteit (binnen 2×).
- Voorbeelden: dotenv, cache en retry (in decorator-overhead) tonen bijna exacte pariteit of kleine winsten.
C-Extension Cliff (Trager): 6 modules zijn aanzienlijk trager (vaak >10×) omdat hun referenties vertrouwen op gecompileerde extensies.
- Voorbeelden: protobuf (6–72× trager dan google-protobuf), png (7–45× trager dan Pillow) en pure-Python aes (300–17.000× trager dan PyCryptodome).
- Mitigatie: De aes-module demonstreert een hybride aanpak, waarbij wordt gedelegeerd aan system OpenSSL via subprocess, wat snelheidswinsten van 1,5–8× oplevert ten opzichte van de referentie, terwijl het toch zero-dependency blijft in packaging.

Effectiviteit van LLM's

Eenvoudige/Gemiddelde Niveaus: LLM's produceren bijna-correcte concepten in 1–5 iteraties, waarbij voornamelijk verfijning van edgecases nodig is.
Subsysteem-niveaus: Complexe modules (bijv. volledige HTTP-clients, protocolstapels) vereisen aanzienlijke menselijke architecturale begeleiding voordat LLM-ondersteuning productief wordt. De LLM versnelt implementatiedetails maar stuurt geen hoog-niveau ontwerp.

Betekenis en Claims

Het artikel beweert dat stdlib-only implementaties levensvatbare vervangers zijn voor de meerderheid van utility- en infrastructuurbibliotheken, wat de aanname uitdaagt dat derde-partij afhankelijkheden noodzakelijk zijn voor prestaties of correctheid.

Omvang van Toereikendheid: Ongeveer twee derde van de bestudeerde modules bereikt prestatiepariteit of beter. De primaire beperking is niet de overhead van Python zelf, maar de afhankelijkheid van derde-partij bibliotheken van C/Rust-extensies voor rekenintensieve taken (beeldverwerking, binaire serialisatie, hardware-versnelde crypto).
Architecturale Overhead: De studie benadrukt dat "bloat" in referentiebibliotheken (abstractielagen, pluginsystemen) vaak een prestatiestraf oplegt die gerichte stdlib-herimplementaties kunnen elimineren.
Rol van LLM's: Door LLM's ondersteunde ontwikkeling is effectief voor beperkte, single-file generatie maar vereist menselijk toezicht voor complexe subsystemen. Het gebruik van een referentiebibliotheek als "oracle" is cruciaal voor iteratieve verfijning.
Praktische Implicatie: Voor omgevingen waar afhankelijkheidsbeheer kostbaar is (bijv. beperkte implementaties, supply chain-beveiliging), biedt zerodep een gecureerde, gebenchmarkde weg naar zero-dependency software zonder betekenisvol verlies in correctheid of prestaties, mits de workload geen native code-versnelling vereist.

De auteurs concluderen dat hoewel pure-Python-implementaties niet kunnen concurreren met native code in ruwe doorvoer voor specifieke domeinen, de combinatie van stdlib-only beperkingen, door LLM's ondersteunde iteratie en subprocess-offloading (waar van toepassing) de kloof voldoende dicht voor een breed scala aan praktische engineeringstaken.