Sorunun geçmişi
Python 2.5, PEP 343 aracılığıyla with ifadesini tanıtmadan önce, kaynak yönetimi, kod tabanları boyunca dağılmış açık try/finally blokları gerektiriyordu. İşlevsel olmasına rağmen, bu desen, basit kaynak edinme ve serbest bırakma senaryoları için uzun ve hataya açık bir yapıya sahipti. contextlib modülü, geliştiricilerin, sıradışı görünen jeneratörleri bağlam yönetimi protokolünü tatmin eden nesnelere dönüştürmek için @contextmanager dekoratörünü kullanarak, bağlam yöneticilerini jeneratör fonksiyonları olarak yazmalarına olanak sağlamak için tanıtıldı.
Sorun
Bir jeneratör fonksiyonu, bağlam yöneticisi protokolü (__enter__, __exit__) değil, iteratör protokolünü (__iter__, __next__) doğrudan uygular. Temel zorluk, bu farklı protokolleri bir araya getirmekte yatmaktadır: with bloğuna girerken, yield öncesindeki kurulum kodu çalıştırılmalıdır; çıkarken, yield sonrası temizlik kodu, istisnalardan bağımsız olarak çalışmalıdır. Dahası, with bloğu içinde yükseltilen istisnalar, jeneratörün duraklama noktası olan yield'e geri enjekte edilmelidir, bu da jeneratörün kendi istisna işleme mantığının temizlik işlemlerini gerçekleştirmesine olanak tanır.
Çözüm
Dekoratör, jeneratör fonksiyonunu GeneratorContextManager sınıfı (modern CPython'da C ile uygulanmıştır) içinde sarar. Her çağrı, taze bir jeneratör iteratörü oluşturur. __enter__ yöntemi, bu iteratörde next() çağrısını yapar, fonksiyonu yield ifadesine kadar çalıştırır ve as değişkenine bağlı olarak dönen değeri döndürür. __exit__ yöntemi, istisna ayrıntılarını alır; eğer bir istisna meydana gelmediyse, jeneratörü tekrar next() çağrısıyla devam ettirir ve tüketir. Bir istisna meydana gelirse, jeneratörün throw() yöntemini çağırır, istisnayı duraklatılmış yield noktasında enjekte eder. Bu, jeneratörün except veya finally bloklarının temizlik gerçekleştirmesine olanak tanır. Eğer throw() normal olarak dönerse (istisna yakalanır), __exit__ True döndürerek istisnayı bastırır; aksi takdirde, istisna yayılır.
from contextlib import contextmanager @contextmanager def managed_connection(): conn = create_connection() try: print("Bağlantı kuruldu") yield conn except NetworkError: conn.rollback() raise finally: conn.close() print("Bağlantı kapatıldı") with managed_connection() as c: c.query("SELECT * FROM data")
Sorun tanımı: Yüksek verimli bir veri işleme servisi, bellek içi tamponlar sınırları aşıldığında geçici dökme dosyalarını yönetmek zorunda kaldı. Eski uygulama, dosya oluşturma ve silme mantığını 12 farklı işleme modülü arasında çoğaltarak, kenar durum hataları sırasında dosya tanımlayıcı sızıntılarına yol açtı ve bakımı zorlaştırdı.
Değerlendirilen çözümler:
Manuel try/finally blokları başlangıçta tercih edilen yaklaşım oldu. Her kullanım alanı, os.unlink()'in çağrıldığından emin olmak için dosya işlemlerini açık try/finally içine sardı. Bu, sıfır soyutlama maliyeti ile açık kontrol akışı sundu, ancak her kullanım yerine sekiz satır ile uzun ve hataya açık oldu. Geliştiriciler zaman zaman temizlik mantığını yanlış finally bloğuna yerleştirdiler ve günlükleme gereksinimleri eklendiğinde tüm modüller arasında davranışı tutarlı bir şekilde değiştirmek zorlayıcıydı.
Sınıf tabanlı bir bağlam yöneticisi, yeniden kullanılabilir bir alternatif olarak değerlendirildi. Bir TempSpillFile sınıfı, dosyayı oluşturmak için __enter__ ve silmek için __exit__ yöntemlerini uygular. Yeniden kullanılabilir ve standart protokolü izlese de, sınıf tanımı kurulum ile temizlik arasında birçok satır ile görsel olarak ayırdı, okunabilirliği olumsuz etkiledi. Ayrıca, kavramsal olarak basit bir kaynak yaşam döngüsü için on beş satırlık bir tekrarlama gerektirdi, bu da gerçek mantığı gizledi.
@contextmanager ile jeneratör yaklaşımı, son seçenek olarak düşünüldü. Bir temp_spill_file() jeneratör fonksiyonu dosyayı oluşturacak, onu yield edecek ve silmek için try/finally kullanacaktı. Bu, kod tekrarlamasını en aza indirdi ve kurulum ile temizlik işlemlerini kaynak kodunda yan yana tuttu, tanıdık istisna işleme sözdizimini kullandı. Ancak, bu tek kullanım sınırlamasını dayattı ve yield duraklama noktası, senkronize yürütme bekleyen geliştiricileri yanıltabilir.
Seçilen çözüm ve sonuç: @contextmanager yaklaşımı, kod tekrarlamasını minimize ederken, kod incelemeleri sırasında netliği maksimize ettiği için seçildi. Edinim ve serbest bırakma mantığının yan yana olması, kaynak yaşam döngüsünün hemen anlaşılmasını sağladı. Yeniden düzenleme, kaynak yönetimi kodunu doksan altı satırdan on iki satıra düşürdü. Statik analiz, üretim kullanımı sırasında sıfır dosya tanımlayıcı sızıntısını doğruladı.
GeneratorContextManager, yield öncesi (kurulum aşamasında) ve yield sonrası (temizlik aşamasında) meydana gelen istisnaları nasıl yönetir?
Eğer jeneratörde yield öncesinde bir istisna meydana gelirse, jeneratör hiç durmaz; __enter__ bu istisnayı hemen yayımlar ve __exit__ hiçbir zaman çağrılmaz. Eğer with bloğu içinde (``yield'den sonra) bir istisna meydana gelirse, jeneratör duraklar. exitardındangenerator.throw(exc_type, exc_val, exc_tb)çağrısını yapar, bu da jeneratörüyieldsatırında aktif bir istisna ile tekrar başlatır. Bu, jeneratörün kendiexceptveyafinallybloklarının çalıştırılmasına olanak tanır. Adaylar genelliklethrow()`'un aslında yürütmeyi tekrar başlattığını ve istisnanın jeneratörün perspektifinden yield ifadesinde meydana geldiği gerçeğini gözden kaçırır.
contextmanager dekoratörüyle işaretlenmiş bir jeneratör neden tek bir yield noktasını zorunlu kılar ve bu kısıtlamanın ihlali durumunda hangi spesifik hata meydana gelir?
Bağlam yöneticisi protokolü, tek bir giriş ve çıkış varsayar. Eğer jeneratör ikinci kez yield ederse—ya __exit__ next() çağrısı yapar (istisna yok) ve jeneratör tekrar yield ederse, ya da throw() çağrılır ve jeneratör istisnayı işlerken tekrar yield ederse—GeneratorContextManager, "jeneratör durmadı" mesajı ile RuntimeError fırlatır. Bu, durum makinesinin temizlemeden sonra jeneratörün tükenmesini beklediğinden meydana gelir. Adaylar genellikle bunun birden fazla yield'in geçerli olduğu standart yineleme ile karıştırır, yield'in bağlam için bir duraklama/devam sınırı işlevi gördüğünü anlamazlar, değer üretim sırası değil.
GeneratorContextManager'ın __exit__ yöntemi, with bloğu içinde oluşan bir istisnayı hangi koşullar altında bastırır ve bu, jeneratörün istisna yönetimi ile nasıl etkileşir?
__exit__, yalnızca throw() ile enjekte edilen istisna jeneratör içinde yakalandığında ve jeneratör sona erdiğinde (örneğin StopIteration yükseldiğinde) ve istisnayı tekrar yükseltmeden ya da yeni bir istisna oluşturmadan, bu istisnayı bastırır (True döndürür). Eğer jeneratör istisnayı yakalarsa ve throw() çağrısının normal bir şekilde geri dönmesine izin verirse, __exit__ bunu başarılı bir şekilde yönetim olarak değerlendirecek ve True döndürecektir. Eğer jeneratör istisneyi yakalamazsa, throw() onu dışarı yayar ve __exit__ None (yanlış) döner, bu da istisnanın yayılmasına izin verir. Adaylar genellikle jeneratör içinde sadece bir try/except bulundurmanın yeterli olmadığını gözden kaçırır; istisna, özellikle throw() çağrısından yakalanmalı ve yeniden yükseltilmemeli, açık bir return ya da yakaladıktan sonra sona düşülmeyi gerektirir.