In CPython, l'implementazione di riferimento di Python, il comportamento di locals() diverge in base all'ambito di esecuzione a causa delle strategie di ottimizzazione. A livello di modulo, locals() restituisce il dizionario dello spazio dei nomi globale stesso, che è il deposito autoritativo per le variabili, quindi le modifiche si riflettono immediatamente nell'ambiente. All'interno di una funzione, invece, CPython impiega un'ottimizzazione chiamata "fast locals", memorizzando le variabili in un array C di dimensioni fisse di puntatori PyObject* indicizzati dal bytecode piuttosto che in una tabella hash. Quando locals() viene chiamato all'interno di una funzione, CPython crea un nuovo dizionario e lo popola copiando i valori da questo array locale veloce, producendo un'istantanea temporanea. Di conseguenza, scrivere in questo dizionario aggiorna solo la mappatura effimera, lasciando invariato l'array locale veloce sottostante, quindi la funzione continua a utilizzare i valori originali delle variabili.
Un team di sviluppo stava creando uno strumento di debug dinamico che consentiva agli sviluppatori di iniettare variabili di utilità temporanee nel mezzo dell'ambito di una funzione in esecuzione tramite un'interfaccia di debugger remoto. L'implementazione iniziale catturava locals() a un punto di interruzione, iniettava oggetti di supporto nel dizionario restituito e si aspettava che la funzione in esecuzione accedesse a questi oggetti di supporto nelle righe successive.
Il primo approccio tentava di mutare il dizionario restituito da locals() direttamente, operando sotto l'assunzione che fosse un riferimento attivo allo spazio dei nomi della funzione. Pro: Non richiedeva modifiche alle firme delle funzioni ed era sintatticamente semplice. Contro: Falliva silenziosamente perché CPython tratta questo dizionario come un'istantanea di sola lettura dell'array locale veloce; le modifiche venivano scartate, lasciando inalterate le effettive variabili locali.
La seconda strategia prevedeva di iniettare lo stato temporaneo in globals() invece, utilizzando lo spazio dei nomi globale come una bacheca condivisa. Pro: Questo metodo persisteva i dati attraverso l'applicazione ed era accessibile ovunque senza passare argomenti. Contro: Introduceva gravi pericoli per la sicurezza dei thread, inquinava lo spazio dei nomi globale con dati di debug temporanei e violava i principi di incapsulamento esponendo lo stato interno all'intero processo.
La soluzione finale ristrutturava le funzioni strumentate per accettare un argomento dizionario context esplicito, attraverso il quale il debugger poteva passare lo stato mutabile. Pro: Questo approccio è esplicito, sicuro per i thread e funziona in modo identico su CPython, PyPy e Jython, aderendo al principio di Python che l'esplicito è migliore dell'implicito. Contro: Ha richiesto di modificare le firme delle funzioni target e i punti di chiamata, il che ha comportato una ristrutturazione iniziale maggiore rispetto agli altri approcci.
Il team ha adottato la strategia di passaggio esplicito del context. Questo ha eliminato la dipendenza dai dettagli specifici dell'implementazione di CPython, ha prevenuto l'inquinamento dello spazio dei nomi e ha portato a uno strumento di debug stabile e multipiattaforma.
Perché locals() si comporta in modo diverso all'interno di una comprensione di lista rispetto a un ciclo for standard a livello di modulo?
In Python 3, le comprensioni di lista introducono il proprio ambito locale, simile a una funzione annidata, per prevenire la perdita di variabili dalla variabile di ciclo nello spazio dei nomi circostante. Quando locals() viene chiamato all'interno di una comprensione, restituisce il dizionario per questo ambito temporaneo, non per la funzione o il modulo circostante. Inoltre, proprio come nelle funzioni regolari, questo dizionario è un'istantanea da fast locals se la comprensione è implementata come un oggetto di codice separato, quindi le scritture in esso non persistono. Al contrario, a livello di modulo, locals() è un alias per globals(), che è il dizionario del modulo attivo. Questa distinzione è fondamentale perché gli sviluppatori spesso presumono che le comprensioni condividano lo stesso spazio dei nomi locale del loro blocco contenente, portando a confusione quando si cerca di eseguire il debug o di iniettare variabili al loro interno.
Puoi forzare un write-back a fast locals manipolando l'oggetto frame tramite sys._getframe(), e quali sono i rischi?
Gli utenti avanzati possono accedere al frame di esecuzione attuale utilizzando sys._getframe() e modificare frame.f_locals, che CPython espone come una mappatura scrivibile. In alcune versioni, assegnare a frame.f_locals può innescare un write-back all'array locale veloce utilizzando API interne come PyFrame_LocalsToFast, ma questo comportamento è dipendente dall'implementazione, fragile alle versioni e non fa parte della specifica del linguaggio. I rischi includono corruzione della memoria se i conteggi di riferimento non vengono gestiti correttamente, comportamento incoerente in cui l'ottimizzatore ignora i valori aggiornati perché li ha già memorizzati nei registri o nell'array, e completo fallimento in altre implementazioni di Python come PyPy che non utilizzano affatto un'architettura di array locali veloci. Fare affidamento su questa tecnica introduce un comportamento indefinito e rende il codice impossibile da mantenere attraverso le versioni di Python.
Come influisce la presenza di exec() o eval() con locals espliciti sull'ottimizzazione di fast locals in una funzione?
Se un corpo di funzione contiene una chiamata exec() o eval() che fa riferimento allo spazio dei nomi locale, CPython non può garantire che le variabili vengano accessibili solo tramite l'array locale veloce ottimizzato; la stringa eseguita potrebbe introdurre o eliminare variabili dinamicamente. Per questo motivo, il compilatore disabilita l'ottimizzazione locale veloce per quella funzione, tornando a memorizzare tutte le variabili locali in un dizionario standard che viene consultato per ogni accesso. In questa modalità "non ottimizzata", locals() restituisce questo dizionario effettivo, rendendolo una visualizzazione vivente e mutabile in cui le modifiche persistono immediatamente. Questo spiega perché il codice che utilizza exec() viene spesso eseguito più lentamente e perché locals() potrebbe apparire per funzionare "correttamente" (consentendo scritture) in tali funzioni, mentre nelle funzioni ottimizzate non lo fa.