RAII in Python: qual è il punto di __del__?

Question

A prima vista, sembra che il metodo speciale Python __del__ offra gli stessi vantaggi di un distruttore in C++. Ma secondo la documentazione di Python (https://docs.python.org/3.4/reference/datamodel.html), c'è non c'è nessuna garanzia che il metodo __del__ del tuo oggetto venga mai chiamato!

Non è garantito che i metodi __del__() vengano chiamati per oggetti che esistono ancora quando l'interprete esce.

Quindi, in altre parole, il metodo è inutile! Non è vero? Una funzione di hook che può o non può essere chiamata in realtà non fa molto bene, quindi __del__ non offre nulla per quanto riguarda RAII. Se ho un po 'di pulizia essenziale, non ho bisogno di eseguire alcune volte, oh, quando mai il GC sembra davvero, ho bisogno di eseguire in modo affidabile, deterministico e al 100% del tempo.

So che Python fornisce i gestori di contesto, che sono molto più utili per tale compito, ma perché è stato mantenuto il __del__? Qual e il punto?

Answer 1

Perché __del__ viene chiamato. È solo che non è chiaro quando lo farà, perché in CPython se si dispone di riferimenti circolari, il meccanismo refcount non può occuparsi del recupero dell'oggetto (e quindi della sua finalizzazione tramite __del__) e delegarlo al garbage collector.

Il garbage collector ha quindi un problema: non può sapere in che ordine interrompere i riferimenti circolari, poiché ciò potrebbe causare ulteriori problemi (ad esempio libera la memoria che sarà necessaria nella finalizzazione di un altro oggetto che è parte del loop raccolto, attivando un segfault).

Il punto da sottolineare è che l'interprete può uscire per ragioni che impediscono di eseguire la pulizia (ad esempio, segfaults, o qualche modulo C chiama in modo imprevisto exit()).

C'è PEP 442 per la finalizzazione di oggetti sicuri che è stata finalizzata in 3.4. Ti suggerisco di dare un'occhiata a questo.

https://www.python.org/dev/peps/pep-0442/

Answer 2

__del__ è un finalizzatore. Non è un distruttore. Finalizzatori e distruttori sono animali completamente diversi.

I distruttori sono chiamati in modo affidabile e esistono solo nelle lingue con gestione della memoria deterministica (come C++). I gestori di contesto Python (la dichiarazione with) possono ottenere effetti simili in determinate circostanze. Questi sono affidabili perché la durata di vita di un oggetto è fissata con precisione; in C++, gli oggetti muoiono quando sono esplicitamente delete d o quando viene chiuso un certo scope (o quando un puntatore intelligente li cancella in risposta alla propria distruzione). E quello è il momento in cui i distruttori corrono.

I finalizzatori non vengono richiamati in modo affidabile. L'unico uso valido di un finalizzatore è come an emergency safety net (NB: questo articolo è scritto da una prospettiva .NET, ma i concetti si traducono abbastanza bene). Ad esempio, gli oggetti file restituiti da open() si chiudono automaticamente quando finalizzati. Ma devi comunque chiuderli tu stesso (ad esempio usando la dichiarazione with). Questo perché gli oggetti vengono distrutti dinamicamente dal garbage collector, che può essere o non essere eseguito immediatamente e, con la garbage collection generazionale, può o meno raccogliere alcuni oggetti in un dato passaggio.Dato che nessuno sa quali tipi di ottimizzazioni potremmo inventare in futuro, è più sicuro presumere che non puoi sapere quando il garbage collector andrà in giro a raccogliere i tuoi oggetti. Ciò significa che non puoi fare affidamento sui finalizzatori.

Nel caso specifico di CPython, si ottengono garanzie leggermente più forti, grazie all'uso del conteggio dei riferimenti (che è molto più semplice e prevedibile della garbage collection). Se è possibile assicurarsi di non creare mai un ciclo di riferimento che coinvolga un determinato oggetto, il finalizzatore dell'oggetto verrà chiamato in un punto prevedibile (quando l'ultimo riferimento muore). Questo è solo true di CPython, l'implementazione di riferimento e non di PyPy, IronPython, Jython o altre implementazioni.