Python'un asenkron bağlam yöneticisi protokolü iki özel dunder metoduna dayanır: __aenter__ ve __aexit__. Senkron karşıtlarının aksine, her ikisi de awaitable coroutine nesneleri döndürmek için async def ile tanımlanmalıdır. async with bloğuna girerken, yorumlayıcı __aenter__ metodunu bekler ve sonucunu as değişkenine bağlar; çıkışta ise istisna detaylarıyla birlikte __aexit__ metodunu bekler ve yalnızca eğer beklenen sonuç truthy ise istisnayı bastırır.
Veri mühendisliği ekibimizin, otomatik olarak işlem mesajı gruplarını yöneten bir async Kafka üreticisi için bir bağlantı yöneticisi uygulaması gerekiyordu. Sorun, yüksek verimli akış sırasında bağlantıların sızmaması şartıyla, bir hata meydana geldiğinde commit() veya abort() metotlarının asenkron olarak çalışmasını sağlamaktı.
Bir yaklaşım, her işlem grubunun etrafında açık try/finally blokları kullanarak manuel kaynak yönetimiydi. Bu, şeffaf bir kontrol sağlarken aynı zamanda geliştiricilerin hata yollarında temizleme coroutine'ini await etmeyi sıkça unuttukları, derinlemesine iç içe geçmiş, hata yapmaya açık bir koda neden oldu ve bu da kaynak tükenmesine ve tutarsız duruma yol açtı.
Diğer bir seçenek, üreticiyi döndüren bir async jeneratörü saran @contextlib.asynccontextmanager dekoratörünü kullanmaktı. Bu, gereksiz kod miktarını azaltsa ve okunabilirliği artırsa da, jeneratör yükü getirdi ve istisna türünü kontrol edip bastırılacak hataları belirlemek için koşullu commit mantığını uygulamayı zorlaştırdı.
Sonuç olarak, özel __aenter__ ve __aexit__ metotları ile ayrılmış bir AsyncKafkaTransaction sınıfı uygulamayı seçtik. Bu çözüm, optimal performans sağladı ve hassas kontrol imkanı sundu: __aenter__ işlem başlangıcını beklerken, __aexit__ istisnanın bir KafkaTimeoutError olup olmadığını kontrol ederek yeniden denemeyi tetikledi (geri dönüş True) veya hatayı yaymayı (geri dönüş False) sağladı, her durumda uygun temizliğin sağlanmasını bekledi.
Sonuç, her gün milyonlarca olayı yönetebilen, bağlantı sızıntısı olmadan ve ağ bölünmeleri sırasında nazik bir şekilde degrade olabilen sağlam bir akış boru hattı oldu, hepsi temiz async with transaction as txn: sözdizimi ile erişildi.
Neden __aenter__ async def ile tanımlanmalıdır, içsel await işlemi yapmasa bile?
Python yorumlayıcısı, bir async with ifadesini işlerken __aenter__ tarafından döndürülen nesneyi şartsız olarak bekler. Eğer bir normal yöntem olarak tanımlanırsa, doğrudan örneği döndürür, ancak yorumlayıcı bir TypeError hatası verir çünkü sonuç awaitable değildir. async def kullanmak, metodun runtime’ın askıya alabileceği ve yeniden başlatabileceği bir coroutine nesnesi döndürmesini sağlar, böylelikle trivial uygulamalar için bile protokol tutarlılığının korunmasını sağlar; bu uygulamalar yalnızca return self ifadesiyle tanımlanmış olabilir.
__aexit__ istisna bastırmayı nasıl sinyaller ve etkili geri dönüş değerinin türü nedir?
__aexit__ bir coroutine metodu olmalıdır, bu nedenle çağırılması bir coroutine nesnesi döndürür ve yorumlayıcı bunun sonucunu bekler. Python runtime’ı bu await işleminin sonucunu inceler; eğer çözülen değer truthy ise (tipik olarak True), istisna bastırılır ve async with bloğu düzgün bir şekilde çıkar. Kritik bir detay, async def fonksiyonu içinde True döndürmenin bunu tatmin ettiğidir; ancak runtime, nihai çözülen değeri kontrol eder, bu da onu senkron __exit__ metodundan ayırır çünkü senkron __exit__ doğrudan değeri döndürür.
Hangi özel koşullarda __aexit__ istisna argümanları None olarak ayarlanır?
__aexit__ üç argüman alır: (exc_type, exc_val, exc_tb), bu argümanların tamamı, async with bloğu gövdesi hata vermeden normal bir şekilde tamamlandığında tam olarak None değerini alır. Bu durum, başarı veya başarısızlığa bakılmaksızın temizleme mantığının çalışmasını sağlamak için zorunludur; adaylar çoğunlukla yalnızca istisna durumlarını ele alan __aexit__ uygulamaları yazar, bu da normal çıkışlarda kaynakları serbest bırakmayı ihmal ederek uzun süreli async uygulamalarda kaynak sızıntılarına yol açar.