Nelle prime versioni di Python, la risoluzione degli attributi si basava su una semplice ricerca in profondità attraverso il dizionario dell'istanza seguita dalla gerarchia delle classi. Questo approccio si è rivelato insufficiente per implementare un comportamento simile a una proprietà robusto, dove i valori calcolati dovevano intercettare sia le letture che le scritture senza ambiguità. L'introduzione delle classi di nuova generazione in Python 2.2 ha stabilito il protocollo dei descriptor, classificando i descriptor in base alla presenza di __set__ o __delete__ per risolvere i conflitti di precedenza.
Senza una regola di precedenza rigorosa, l'interprete non poteva decidere se lo storage locale di un'istanza dovesse sovrascrivere le definizioni a livello di classe o viceversa. Se i dizionari delle istanze avessero sempre avuto la precedenza, le proprietà non avrebbero potuto convalidare le assegnazioni perché i valori sarebbero stati memorizzati direttamente in __dict__. D'altra parte, se gli attributi di classe avessero sempre dominato, le normali variabili di istanza sarebbero state inaccessibili quando i nomi collidevano con metodi o altri attributi di classe.
L'algoritmo di ricerca degli attributi di Python richiede che i descriptor di dati—quelli che definiscono __set__ o __delete__—abbiano la precedenza sui dizionari delle istanze, mentre i descriptor non di dati (che definiscono solo __get__) cedono ai dizionari delle istanze. Questo design consente a @property di imporre una logica di convalida intercettando le scritture, mentre le funzioni ordinarie o le proprietà memorizzate possono rimanere sovrascrivibili per istanza senza una metaprogrammazione complessa.
Un team di sviluppo stava costruendo uno strato di convalida dei dati ad alta capacità per una piattaforma di trading finanziario. Richiedevano campi persistenti che convalidassero rigorosamente i dati di mercato in ingresso rispetto ai vincoli normativi, assicurandosi che valori non validi non potessero essere assegnati. Inoltre, avevano bisogno di metriche calcolate che potessero essere memorizzate per istanza per evitare costose ricalcolazioni degli indici di volatilità durante i picchi di trading ad alta frequenza.
Un approccio considerato era implementare tutti gli attributi come proprietà usando il decoratore @property. Questo forniva un controllo di convalida completo intercettando ogni operazione di scrittura attraverso il metodo setter della proprietà. Tuttavia, questo design impediva al sistema di bypassare la convalida quando caricava dati serializzati da cache interne fidate, creando un overhead computazionale non necessario durante le operazioni di riproduzione in blocco.
Un'altra opzione prevedeva di sovrascrivere __setattr__ nella classe base per centralizzare la logica di convalida all'interno di un unico metodo. Sebbene questo controllo centralizzato offrisse un unico punto di modifica per le regole di convalida, introduceva una logica di ramificazione fragile per distinguere tra campi persistenti che richiedono convalida e cache computazionali temporanee. Inoltre, questo approccio interferiva con i modelli di accesso agli attributi standard attesi dalle librerie di serializzazione di terzi, causando guasti di integrazione.
La soluzione scelta ha sfruttato direttamente la dicotomia del protocollo dei descriptor per soddisfare entrambi i requisiti senza l'overhead della centralizzazione. Il team ha implementato ValidatedField come un descriptor di dati con un metodo __set__ che impone vincoli di tipo e di gamma, assicurandosi che intercettasse sempre le assegnazioni indipendentemente dallo stato dell'istanza, poiché i descriptor di dati hanno la precedenza sui dizionari delle istanze. Per le metriche calcolate, hanno creato CachedMetric come un descriptor non di dati implementando solo __get__, permettendo al dizionario dell'istanza di sovrascrivere il descriptor una volta che un valore è stato calcolato e memorizzato localmente, bypassando quindi il ricalcolo sugli accessi successivi.
Questa architettura ha fornito una convalida rigorosa per gli input esterni mentre permetteva una memorizzazione flessibile e performante per i valori derivati. Il sistema ha elaborato con successo flussi di mercato ad alto volume senza colli di bottiglia nelle convalide durante l'idratazione della cache. Il benchmarking ha rivelato una riduzione del 40% dell'overhead di convalida durante scenari di riproduzione storica rispetto all'approccio solo con proprietà, mantenendo nel contempo la piena conformità normativa per l'ingestione di dati dal vivo.
Cancellare un attributo bypassa un data descriptor se il descriptor non ha un metodo __delete__?
Quando un data descriptor implementa __set__ ma omette __delete__, tentare di eliminare l'attributo tramite del obj.attr non ritorna al dizionario dell'istanza. Python riconosce ancora l'oggetto come un data descriptor a causa della presenza di __set__, e l'operazione di eliminazione solleverà un AttributeError indicando che l'attributo non può essere eliminato. Per consentire l'eliminazione, il descriptor deve definire esplicitamente __delete__ per rimuovere il valore dall'istanza, oppure la classe deve implementare una logica di eliminazione personalizzata; il meccanismo di ricerca non controlla mai il dizionario dell'istanza per gli attributi dei data descriptor durante le operazioni di eliminazione.
Perché super().attribute sembra ignorare i data descriptor definiti sulla classe corrente?
Il proxy super() implementa un meccanismo di eredità multipla cooperativa che inizia a cercare l'Ordine di Risoluzione dei Metodi (MRO) nella classe successiva alla classe corrente nella gerarchia. Poiché il descriptor è definito sulla classe corrente stessa, super() lo salta durante la ricerca. Tuttavia, se una classe genitore definisce un data descriptor con lo stesso nome, super() lo troverà e applicherà le regole standard di precedenza dei data descriptor, invocando __get__ con l'istanza e la classe proprietaria in modo appropriato. Questo comportamento deriva dal punto di partenza dell'MRO, non da un'eccezione speciale per i descriptor negli oggetti proxy di super.
Come utilizzano __slots__ il protocollo dei descriptor per imporre vincoli di memorizzazione?
Quando una classe definisce __slots__, l'interprete Python crea automaticamente descriptor interni specializzati (tipicamente oggetti member_descriptor a livello C) per ogni nome di slot e li inserisce nel dizionario della classe. Questi descriptor implementano sia __get__ che __set__, rendendoli data descriptor che hanno la precedenza su qualsiasi tentativo di memorizzare valori in un dizionario delle istanze convenzionale. Poiché le istanze delle classi con slot mancano tipicamente di un __dict__ a meno che "__dict__" non sia esplicitamente incluso nell'elenco degli slot, il protocollo dei descriptor assicura che tutte le letture e scritture per gli attributi con slot siano canalizzate attraverso questi descriptor a livello C, imponendo la sicurezza dei tipi e l'efficienza della memoria impedendo l'attaccamento di attributi arbitrari.