Descriptorler Python 2.2'de yeni stil sınıflarla birlikte, özellik erişim kontrolü için birleşik bir protokol sağlamak üzere resmileştirildi. Bu yenilikten önce, property ve classmethod gibi yerleşik türler, kesin durum mantığına dayanan bir şekilde yorumlayıcıya yerleştirilmişti. Descriptor protokolünün tanıtımı, kullanıcı tanımlı sınıfların daha önce yalnızca yerleşiklerde bulunan davranışları sergilemesine olanak tanıdı. None parametresinin sınıf seviyesindeki ve örnek seviyesindeki erişimi ayırt etmek için geçiştirilmesi, protokolü birden fazla yönteme ayrıştırmadan yönetme ihtiyacından kaynaklandı.
Sınıfın kendisinde erişim olduğunda bunu tespit etmek için bir mekanizma olmadan, descriptorler kendilerini koşulsuz olarak döndürmeye zorlanacaktı, bu da sınıf seviyesinde özelliklerin veya şema içgörüsünün uygulanmasını engelleyecekti. Alternatif olarak, protokol sınıf ve örnek erişimi için ayrı kanca yöntemlerini gerektirirdi, bu da nesne modelini önemli ölçüde karmaşıklaştırırdı. Zorluk, hem erişim kalıplarını zarif bir şekilde ele alabilen bir tek yöntem imzası tasarlarken, geriye dönük uyumluluğu korumak ve minimum performans yükü sağlamakta yatıyordu.
__get__(self, instance, owner) yöntem imzası, Class.attribute olarak erişildiğinde instance parametresi için None ve instance.attribute olarak erişildiğinde gerçek örnek nesnesini alır. owner parametresi her zaman tanımlayıcı sınıfı alır. Bu, descriptorlerin dallanmış mantık uygulamasına olanak tanır: instance is None olduğunda meta verileri veya descriptorün kendisini döndürmek ya da bir örnek mevcut olduğunda hesaplanmış değerleri döndürmek. Bu gelenek, saf Python içinde classmethod ve staticmethod uygulamasını sağlar ve sınıf seviyesi doğrulama şemaları gibi gelişmiş desenleri destekler.
Bir veri mühendisliği ekibi, alan tanımlarının otomatik OpenAPI belge üretimi için sınıf üzerinde denetlendiğinde meta veri sağladığı, ancak örnekler üzerinde erişildiğinde veri doğrulaması yaptığı bir deklaratif doğrulama çerçevesine ihtiyaç duydu. Naif descriptorler kullanan ilk uygulama, User.email sınıfındayken ham descriptor nesnesini döndürdüğü için başarısız oldu, bu da herhangi bir tür bilgisi veya kısıtlaması sunmuyordu.
Düşünülen bir yaklaşım, meta veri alma için ayrı sınıf yöntemleri uygulamaktı. Bu, sınıf sözlüğünü manuel olarak inceleyerek alan bilgilerini çıkarmak için bir get_schema() yöntemi oluşturmaya yönelikti. Genç geliştiriciler için açık ve anlaşılır olsa da, bu, alan tanımları ile içgörü yetenekleri arasında tehlikeli bir kopukluk yarattı. Artıları: İleri düzey Python bilgisi gerektirmeyen basit bir uygulama. Eksileri: DRY ilkesini ihlal etti, paralel mantık yapılarının bakımını gerektirdi ve alan tanımları evrildiğinde hata yapma olasılığı yüksek oldu.
İkinci yaklaşım, __get__ içindeki if instance is None kontrolü yaparak descriptor protokolünün None geleneğinden faydalandı. Bu koşul doğru olduğunda, descriptor; tür kısıtlamaları ve doğrulayıcıları içeren bir FieldSchema nesnesi döndürür; aksi takdirde, doğrulama yapar ve gerçek değeri döndürür. Artıları: Tek bir özellik adı altında birleştirilmiş API, Pythonic geleneklere uyum, otomatik miras desteği. Eksileri: CPython özellik alma mekanizmasını derinlemesine anlama gerektiriyordu ve descriptor iç yapıları hakkında bilgisi olmayan geliştiriciler için hata ayıklamasını zorlaştırıyordu.
Üçüncü bir seçenek, sınıf oluşturma sürecini kesmek ve şema erişimi için sentetik özellikler eklemek üzere bir metaclass kullanmaktı. Bu, sınıf davranışını tamamen kontrol etme imkanı sunmasına rağmen, sınıf hiyerarşisine önemli bir karmaşıklık getirdi ve hata ayıklama çabalarını zorlaştırdı. Artıları: Tam davranışsal kontrol. Eksileri: Gereksinimlere fazla mühendislik, yöntem çözüm sırası hesaplamalarını etkileyen ve ithalat süresi yükünü önemli ölçüde artıran bir durum.
Ekip, mevcut CPython mekanizmalarını kullanan ikinci çözümü seçti, ek soyutlama katmanları getirmedi. None kontrolü, belgelerin oluşturulma zamanı ile çalışma zamanı erişim kalıpları arasında ayırt edici bir bağlam sağladı ve açık yöntem yaklaşımına kıyasla kod tabanını %40 oranında azalttı.
Sonuç olarak, User.email kapsamlı bir şema nesnesi döndürürken, user.email doğrulanmış dize değerini döndürdü. Bu çift davranış, basit sınıf incelemesi yoluyla otomatik OpenAPI spesifikasyonlarının üretilmesine olanak tanıdı, belge bakımını %90 oranında azalttı ve uygulama ile belge arasında senkronizasyon hatalarının tüm bir kategorisini ortadan kaldırdı.
Veri descriptorleri (hem __get__ hem de __set__ implementasyonu) ile veri olmayan descriptorler arasındaki özellik çözüm önceliklendirmesi nasıl farklılık gösterir ve bu ayrım bazı durumlarda örnek sözlüklerinin sınıf özelliklerini gölgelemesini neden engeller?
Veri descriptorleri hem __get__ hem de __set__ yöntemlerini uygular, veri olmayan descriptorler ise yalnızca __get__ yöntemini uygular. Python'daki özellik çözüm mekanizmasında, veri descriptorleri örneğin __dict__ 'sine karşı öncelik alır. Bu, instance.attr'a atama yapıldığında her zaman descriptorün __set__ yöntemini çağıracağı anlamına gelir, örnek daha önce sözlüğünde o anahtara sahip olsa bile. Tersine, veri olmayan descriptorler, örnek sözlüğünün bunları gölgelemesine izin verir; eğer instance.attr = value ataması yaparsanız, örnek __dict__'e yeni bir giriş kazandırır ve sonraki erişimler bu değeri alır, descriptorü çağırmaz. Bu ayrım, önbellekli özelliklerin (veri olmayan) uygulanması ile salt okunur özelliklerin (veri) uygulanması için kritik öneme sahiptir. Adaylar sıklıkla yalnızca __set__ tanımlamanın, yöntem yalnızca AttributeError fırlatsa bile, arama anlamsalını değiştirdiğini gözden kaçırır; bu, property nesnelerinin değişmezliği nasıl sağladığıdır.
Özel descriptorlerin __init__ içinde nitelik adını yakalamak yerine __set_name__ yöntemini neden uygulaması gerekir, özellikle de aynı descriptor örneği birden fazla sınıf özelliğine atandığında veya miras ile kullanıldığında?
Tek bir descriptor örneği birden fazla adı atandığında (örneğin, x = y = MyDescriptor()), __init__ içinde adı saklamak, ikinci atamanın birincisini üzerine yazmasına neden olur ve bu, yanlış ad çözümlemesine yol açar. Dahası, sınıf mirası sırasında, üst sınıf descriptorleri alt sınıflar için yeniden başlatılmaz. Python 3.6'da tanıtılan __set_name__ yöntemi, sınıf oluşturulurken yorumlayıcı tarafından tam olarak bir kez çağrılır ve hem sahip sınıfı hem de niteliğin adını alır. Bu, karmaşık miras veya birden fazla atama ile bile doğru bağlamayı güvence altına alır. Bu yöntem olmadan, descriptorler doğru hata mesajları üretemez veya niteliğin adını gerektiren içgörü yapamaz, bu da metaprogramlama işlemleri sırasında sessiz başarısızlıklara neden olur.
Descriptor protokolü __slots__ ile nasıl etkileşir ve özellikle bir slotted sınıfta özelleştirilmiş descriptorün adı bir slot ile paylaşıldığında hangi belirli hata modu meydana gelir?
Python'un __slots__ mekanizması, sabit boyutlu dizilerde özellik depolamak için veri descriptorlerini dahili olarak uygular. __slots__ = ['name'] tanımladığınızda, CPython sınıf sözlüğünde name için bir descriptor oluşturur. Eğer daha sonra def name(self): ... ile özel bir descriptor tanımlarsanız, slot descriptorünü geçersiz kılarsınız ve slot mekanizmasını tamamen bozar. Bu, slot depolamasına erişmek için gerekli C düzeyi slot protokollerine sahip olmayan özel descriptor nedeniyle AttributeError ile sonuçlanır. Adaylar sıklıkla slot descriptorlerinin veri descriptorleri olduğunu ve özel C uygulamaları içerdiğini gözden kaçırır. Çözüm, özel descriptor için farklı bir nitelik adı kullanmak ya da özenle orijinal slot descriptorinin __get__ ve __set__ yöntemlerine delegasyon yapmaktır; ancak bu, sonsuz rekursiyonu önlemek için titiz bir yönetim gerektirir.