der destruktor bei der OOP

[cyberangle]

Hallo zusammen,

ich lerne Python und bin in meinem Buch bei der opjektorientierten Programmierung.

Da speziell bei dem Konstruktor und Destruktor.
Beim Konstuktor funktioniert die Progammierung wie in Buch beschrieben, aber bein Destuktor nicht.
Beim Aufruf des Destuktor um eine Opjekt zu löschen wird dieses auch entfernt, aber am Programmende
werden alle restlichen Obekte auch entfernt sodas alle Objekte gelöscht sind.

Im ganzen Programmtext erscheint aber nur 1 Mal der Befehl zum Aufruf zur Methodes
>>> del porsche
lt. meinem Buch sollte dann auch nur das eine Objekt gelöscht werden und nicht am Programmende auch noch der
Rest.

Weis einer von Euch Rat???

[Sirius3]

Ich hoffe das Buch hat einen guten Brennwert. In Python von Konstruktoren und Destruktoren zu reden, ist etwas ungenau. Es gibt eine Methode __init__ zum Initialisieren von Objekten und eine Methode __del__ die beim Abräumen des Objekts durch den Garbage-Collector aufgerufen wird. Da am Ende des Programms alle Objekte abgeräumt werden, wird diese Methode natürlich immer aufgerufen.
Das `del`-Statement hat nichts mit dem Löschen eines Objekts zu tun, das kannst Du nämlich gar nicht. `del` entfernt nur einen Namen aus dem aktuellen Namespace. Da das Löschen eines Namens selten Sinn macht, benutzt man del so gut wie nie.

[cyberangle]

Danke, damit hast Du mir schon geholfen, denn genau um __del__ ging es. Im Buch stand nicht, dass am Ende dess Programmes alle Objekte
abgeräumt werden. Für jedes Objekt kam die Meldung Objekt gelöscht.

[narpfel]

@cyberangle: Es ist nicht garantiert, dass am Ende des Programms die `__del__`-Methode aller Objekte aufgerufen wird:

Code: Alles auswählen

class Foo:
    def __init__(self):
        print("Foo.__init__()")

    def __del__(self):
        print("Foo.__del__()")


Foo()

Ergibt

Code: Alles auswählen

$ pypy3 t.py
Foo.__init__()

Es ist in jeder Hinsicht optional, dass `__del__` aufgerufen wird. Da darf man sich nicht drauf verlassen.

[__blackjack__]

Als Ergänzung: Darum gibt es ``with`` und Kontextmanager falls man garantiert Ressourcen aufräumen will/muss. Wenn man also den Drang verspürt `__del__()` zu implementieren, sollte man in aller Regel eher `__enter__()` und `__exit__()` implementieren oder eine Methode oder Funktion mit `contextlib.contextmanager()` dekorieren.

`__del__()` kann, wenn man auf die Gefahren achtet, in einigen wenigen Fällen sinnvoll sein, in denen man externe Ressourcen freigeben möchte und Kontextmanager nicht in Frage kommen. Ich glaube ich habe das bisher nur für eine handvoll Fälle mit externen C-APIs gebraucht die ich mit `ctypes` angebunden habe. Also nichts was irgendwie zu den Grundlagen von Python-Programmierung gehören würde.

[sparrow]

Handelt es sich einmal mehr um das Buch von Ernesti/Kaiser?

[DasIch]

Die Python Dokumentation geht auf die ganzen Probleme mit __del__ ziemlich gut ein https://docs.python.org/3/reference/dat ... ject.__del__.

Was die Dokumentation nicht erwähnt ist dass sich die Konsequenzen davon __del__ zu implementieren im Laufe der Zeit geändert haben auch zwischen unterschiedlichen Minor Versionen. Es war z.B. mal möglich das __del__ mehrfach auf dem selben Objekt aufgerufen wird oder dass __del__ zu Memory Leaks führt.

Selbst wenn man das notwendige Wissen hat um __del__ richtig zu implementieren, ist es sehr schwer dies ohne Fehler richtig hinzubekommen, vor allem weil man es nicht wirklich testen kann. Das notwendige Wissen haben allerdings auch sehr erfahrene und gute Python Entwickler i.d.R. nicht. Man muss schon viel über die Implementation(en) selbst wissen um wirklich zu verstehen was da passiert und was man bedenken muss.

[cyberangle]

Sorry hatte eine Woche keine Zeit

Hallo Sparrow dasBuch ist von Rheinwerk Computing v on Thomas Theis Einstieg in Python

[snafu]

dasBuch ist von Rheinwerk Computing v on Thomas Theis Einstieg in Python

Das ist ein sehr beliebtes Buch bei Anfängern. Andererseits ist es schon in mehreren Punkten durch größere Fehler aufgefallen, weil es Dinge beschreibt, die man so nicht in typischen Python-Programmen machen würden, sondern eher in Sprachen wie Java. Es steht nicht nur Müll drin, aber gerade das Thema OOP ist darin mit Vorsicht zu genießen.