Geschiedenis van de vraag
Voordat Python 2.5 de with-verklaring introduceerde via PEP 343, vereiste resourcebeheer expliciete try/finally-blokken verspreid over codebases. Hoewel functioneel, was dit patroon omslachtig en foutgevoelig voor eenvoudige acquisitie- en vrijgave-scenario's. De module contextlib werd geïntroduceerd om deze boilerplate te verminderen door ontwikkelaars in staat te stellen contextmanagers als generatorfuncties te schrijven, met behulp van de @contextmanager-decorator om ogenschijnlijk sequentiële generators om te zetten in objecten die voldoen aan het contextbeheerprotocol.
Het probleem
Een generatorfunctie implementeert van nature het iteratorprotocol (__iter__, __next__), niet het contextmanagerprotocol (__enter__, __exit__). De fundamentele uitdaging ligt in het overbruggen van deze verschillende protocollen: bij het binnenkomen van een with-blok, moet de setupcode vóór de yield worden uitgevoerd; bij het verlaten moet de opruimcode na de yield worden uitgevoerd, ongeacht uitzonderingen. Bovendien moeten uitzonderingen die binnen het with-blok worden opgegooid, terug in de generator worden geïnjecteerd op het exacte yield-suspensiepunt, zodat de eigen exception-handlinglogica van de generator opruimoperaties kan uitvoeren.
De oplossing
De decorator wikkelt de generatorfunctie in een GeneratorContextManager-klasse (geïmplementeerd in C in moderne CPython). Elke aanroep creëert een nieuwe generatoriterator. De __enter__-methode roept next() aan op deze iterator, waardoor de functie wordt uitgevoerd tot de yield-instructie, en retourneert de yielded-waarde die aan de as-variabele moet worden gebonden. De __exit__-methode ontvangt details van de uitzondering; als er geen uitzondering is opgetreden, roept deze opnieuw next() aan om de generator voort te zetten en uit te putten. Als er een uitzondering is opgetreden, roept deze de throw()-methode van de generator aan, waarbij de uitzondering op het geschorste yield-punt wordt geïnjecteerd. Dit stelt de except- of finally-blokken van de generator in staat om opruiming uit te voeren. Als throw() normaal retourneert (uitzondering gevangen), retourneert __exit__ True om de uitzondering te onderdrukken; anders wordt deze doorgegeven.
from contextlib import contextmanager @contextmanager def managed_connection(): conn = create_connection() try: print("Verbinding tot stand gebracht") yield conn except NetworkError: conn.rollback() raise finally: conn.close() print("Verbinding gesloten") with managed_connection() as c: c.query("SELECT * FROM data")
Probleemomschrijving: Een dataverwerkingsdienst met hoge doorvoer moest tijdelijke spill-bestanden afhandelen wanneer de in-memory buffers de limieten overschreden. De legacy-implementatie dupliceerde de logica voor het maken en verwijderen van bestanden over 12 verschillende verwerkingsmodulen, wat leidde tot lekkages van bestandsdescriptoren tijdens randvoorwaardelijke foutcondities en de onderhoud complicerend.
Overwogen oplossingen:
Handmatige try/finally-blokken waren de eerste benadering. Elke gebruikslocatie omhulde bestandsbewerkingen in expliciete try/finally om ervoor te zorgen dat os.unlink() werd aangeroepen. Dit bood expliciete controleflow zonder abstractie-overhead, maar bleek omslachtig met acht regels per gebruikslocatie en zeer foutgevoelig. Ontwikkelaars plaatsten af en toe opruimlogica in het verkeerde finally-blok en het consistent wijzigen van het gedrag over alle modules was moeizaam toen logvereisten werden toegevoegd.
Een klasse-gebaseerde contextmanager werd beschouwd als een herbruikbaar alternatief. Een TempSpillFile-klasse zou __enter__ implementeren om het bestand te maken en __exit__ om het te verwijderen. Hoewel herbruikbaar en volgbaar met het standaardprotocol, scheidde de klasdefinitie visueel de setup van de opruiming door vele regels, wat de leesbaarheid schaadde. Het vereiste ook vijftien regels boilerplate voor wat conceptueel een eenvoudige levenscyclus van een bron was, waardoor de werkelijke logica werd vervaagd.
De generator met de @contextmanager-benadering was de laatste optie. Een temp_spill_file()-generatorfunctie zou het bestand maken, het yielden en try/finally gebruiken voor de verwijdering. Dit minimaliseerde duplicatie van de code en hield setup en opruiming naast elkaar in de broncode, gebruikmakend van een vertrouwde syntaxis voor exception handling. Het legde echter een beperking op voor eenmalig gebruik en het yield-suspensiepunt kon ontwikkelaars verwarren die een synchrone uitvoering verwachtten.
Gekozen oplossing en resultaat: De @contextmanager-benadering werd geselecteerd omdat deze duplicatie van code minimaliseerde, terwijl deze tegelijkertijd duidelijkheid maximaliseerde tijdens codebeoordelingen. De nabijheid van acquisitie- en vrijgavelogica maakte de levenscyclus van de bron onmiddellijk duidelijk. De refactoring reduceerde de code voor resourcebeheer van zesennegentig regels tot twaalf regels in de codebase. Staticale analyse bevestigde nul lekkages van bestandsdescriptoren tijdens het daaropvolgende kwartaal van productiegebruik.
Hoe gaat GeneratorContextManager om met uitzonderingen die optreden tijdens de setupfase (voor de yield) versus de opruimfase (na de yield)?
Als er een uitzondering optreedt vóór de yield in de generator, wordt de generator nooit geschorst; __enter__ geeft deze uitzondering onmiddellijk door en __exit__ wordt nooit aangeroepen. Als er een uitzondering optreedt binnen het with-blok (na yield), wordt de generator geschorst. __exit__ roept dan generator.throw(exc_type, exc_val, exc_tb) aan, waarmee de generator wordt hervat op de yield-lijn met de uitzondering actief. Dit stelt de eigen except- of finally-blokken van de generator in staat om uit te voeren. Kandidaten missen vaak dat throw() daadwerkelijk de uitvoering hervat en dat de uitzondering wordt beschouwd als zijnde bij de yield-expressie vanuit het perspectief van de generator.
Waarom handhaaft een contextmanager-gedecoreerde generator een enkel yield-punt, en welke specifieke fout treedt op als deze beperking wordt geschonden?
Het contextmanagerprotocol gaat uit van een enkele invoer en uitgang. Als de generator een tweede keer yieldt—ofwel omdat __exit__ next() aanroept (geen uitzondering) en de generator opnieuw yieldt in plaats van te retourneren, of omdat throw() wordt aangeroepen en de generator de uitzondering behandelt en vervolgens weer yieldt—verhoogt de GeneratorContextManager een RuntimeError met de boodschap "generator stopte niet". Dit gebeurt omdat de toestandsmachine verwacht dat de generator is uitgeput na de opruiming. Kandidaten verwarren dit vaak met standaard iteratie waar meerdere yields geldig zijn, zonder te beseffen dat de yield fungeert als een schors-/herstartgrens voor de context, niet als een waardeproductiesequentie.
Onder welke omstandigheden onderdrukt de __exit__-methode van een GeneratorContextManager een uitzondering die in het with-blok is opgegooid, en hoe werkt dit samen met de exceptie-afhandeling van de generator?
__exit__ onderdrukt de uitzondering (retourneert True) alleen als de geïnjecteerde uitzondering via throw() wordt gevangen binnen de generator en de generator zijn einde bereikt (verhoogt StopIteration) zonder de uitzondering opnieuw te verhogen of een nieuwe op te werpen. Als de generator de uitzondering vangt en toestaat dat de throw()-aanroep normaal retourneert, interpreteert __exit__ dit als succesvolle afhandeling en retourneert True. Als de generator de uitzondering niet opvangt, wordt throw() naar buiten doorgegeven, en __exit__ retourneert None (vals), waardoor de uitzondering kan voortduren. Kandidaten missen vaak dat simpelweg een try/except binnen de generator niet voldoende is; de uitzondering moet specifiek worden gevangen uit de throw()-aanroep en mag niet opnieuw worden opgegooid, en dat een expliciete return of het uiteindigen van de functie na het vangen vereiste is voor onderdrukking.