RAII in Python: Was ist der Sinn von __del__?

Question

Auf den ersten Blick scheint es so, als ob Pythons __del__ spezielle Methode die gleichen Vorteile bietet, die ein Destruktor in C++ hat. Aber laut der Python-Dokumentation (https://docs.python.org/3.4/reference/datamodel.html) gibt es keine Garantie, dass die Methode Ihres Objekts __del__ jemals überhaupt aufgerufen wird!

Es ist nicht garantiert, dass __del__() -Methoden für Objekte aufgerufen werden, die beim Beenden des Interpreters noch vorhanden sind.

Mit anderen Worten, die Methode ist nutzlos! Ist es nicht? Eine Hook-Funktion, die aufgerufen werden kann oder nicht, hilft nicht wirklich, also bietet __del__ nichts in Bezug auf RAII. Wenn ich einige wesentliche Aufräumarbeiten habe, brauche ich es nicht einige Zeit, oh, wenn jemals der GC fühlt es wirklich, ich brauche es zuverlässig, deterministisch und 100% der Zeit laufen.

Ich weiß, dass Python bietet Kontext-Manager, die für diese Aufgabe viel nützlicher sind, aber warum wurde __del__ überhaupt gehalten? Was ist der Punkt?

Answer 1

Weil __del__ aufgerufen wird. Es ist nur unklar, wann es so sein wird, denn in CPython, wenn Sie Zirkelverweise haben, kann der Refcount-Mechanismus die Objektrückgewinnung (und somit dessen Finalisierung über __del__) nicht übernehmen und muss sie an den Garbage Collector delegieren. Der Müllsammler hat dann ein Problem: Er kann nicht wissen, in welcher Reihenfolge die Zirkelbezüge zu brechen sind, weil dies zusätzliche Probleme auslösen kann (zB den Speicher freigibt, der bei der Fertigstellung eines anderen Teiles benötigt wird) der gesammelten Schleife, Auslösen eines segfault). Der Punkt, den Sie betonen, liegt darin, dass der Interpreter möglicherweise aus Gründen, die die Säuberung verhindern, beendet wird (z. B. segfolds oder ein C-Modul ruft exital exit() auf).

Es gibt PEP 442 für die sichere Objekt-Finalisierung, die in 3.4 abgeschlossen wurde. Ich schlage vor, Sie sehen es sich an.

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

Answer 2

__del__ ist ein Finalizerthread. Es ist kein Destruktor. Finalizer und Destruktoren sind völlig verschiedene Tiere.

Destruktoren werden zuverlässig bezeichnet und existieren nur in Sprachen mit deterministischer Speicherverwaltung (wie C++). Pythons Kontextmanager (die with-Anweisung) können unter bestimmten Umständen ähnliche Effekte erzielen. Diese sind zuverlässig, weil die Lebensdauer eines Objekts genau festgelegt ist; In C++ sterben Objekte, wenn sie explizit sind oder wenn ein Bereich verlassen wird (oder wenn ein intelligenter Zeiger sie als Reaktion auf seine eigene Zerstörung löscht). Und dann laufen Destruktoren.

Finalizer werden nicht zuverlässig aufgerufen. Die einzige gültige Verwendung eines Finalizers ist an emergency safety net (NB: dieser Artikel ist aus einer .NET-Perspektive geschrieben, aber die Konzepte übersetzen ziemlich gut). Zum Beispiel schließen sich die Dateiobjekte, die von open() zurückgegeben werden, automatisch bei Abschluss. Aber Sie sollten sie immer noch selbst schließen (z. B. mit der with-Anweisung). Dies liegt daran, dass die Objekte vom Garbage Collector dynamisch zerstört werden, was sofort passieren kann oder auch nicht, und bei der generationsbedingten Garbage Collection kann sie einige Objekte in einem bestimmten Durchgang sammeln oder nicht.Da niemand weiß, welche Optimierungen wir in Zukunft entwickeln könnten, ist es am sichersten anzunehmen, dass Sie nicht wissen können, wann der Garbage Collector zum Sammeln Ihrer Objekte kommt. Das heißt, Sie können sich nicht auf Finalizer verlassen.

Im speziellen Fall von CPython, erhalten Sie etwas stärkere Garantien, dank der Verwendung von Referenzzählung (die viel einfacher und vorhersehbarer als Garbage Collection). Wenn Sie sicherstellen können, dass Sie niemals einen Referenzzyklus für ein bestimmtes Objekt erstellen, wird der Finalizer dieses Objekts an einem vorhersagbaren Punkt aufgerufen (wenn die letzte Referenz stirbt). Dies ist nur gilt für CPython, die Referenz-Implementierung und nicht von PyPy, Ironpython, Jython oder andere Implementierungen.