clear-Befehl wie in Matlab??

[birkenfeld]

Da hast du wohl was falsch verstanden. Das, was im Kontext von CPython als "GC" bezeichnet wird, ist der in IIRC 2.0 neue Cyclic Garbage Collector, der eben genau deswegen eingeführt wurde, weil zyklische Referenzen vorher Probleme machten.

Ah, schön zu hören Das heißt das es nun Quasi zwei GCs in Python gibt oder der alte aufgebohrt wurde um das Erreichbarkeitsproblem im Graphen zu behandeln? Weil, der eigentliche GC basiert doch immer noch auf einer Referenzzählung, was man auch in den Python Extensions sehen kann (XINCREF, XDECREF).
[/quote]
Ja, reference counting ist das hauptsächliche memory management. Der zyklische GC springt nur von Zeit zu Zeit an und kümmert sich um zirkuläre Referenzen.

Hättest du vielleicht einen Link bezüglich des GCs von Python, wo die Funktionsweise genau spezifiziert ist?

Nein, auf die Schnelle nicht. Es müsste sich allerdings in den python-dev-Archiven einiges finden lassen aus der Zeit, in der der GC eingebaut wurde (um 2000 herum).

Mal "eine" Frage, da du ja ein Dev im Core Team bist:
1. Warum hat man sich gegen einen Mark-and-Sweep entschieden bzw. nicht in betrachte gezogen? Die von mir im ersten Post Zitierte Begründung kann es doch irgendwie nicht sein.

Da ich damals nicht dabei war, kann ich nur vermuten: Reference counting funktioniert soweit ja einwandfrei und schnell. Es ermöglicht deterministische Destruktion, wenn man alle Referenzen kennt. Das Hinzufügen des zyklischen GC war wahrscheinlich auch wesentlich einfacher, als das gesamte memory management auszutauschen.

2. Ist für Py3K eine Reformierung des Python GCs geplant? Eventuell Mark-and-Sweep

Nein, solange keiner wirkliche Gründe und einen Patch liefert.

[poker]

@birkenfeld
Ich danke dir recht herzlich für diese aufschlussreichen Informationen, die meinen alten Wissenstand zu recht gerückt haben. Das Archeiv von 2000 werde ich bei Zeit durchforsten.

Den Mechanismus mit den Referenzzählern sehe ich irgendwie nicht als GC an.

Sonder was soll es sonst sein?

Ich glaube aber Du hast das Problem mit der `__del__()`-Methode nicht ganz erfasst.

Das kann natürlich sein.

Aber die Dokumentation bezüglich ``__del__`` und des GCs kenne ich ja schon sehr lange ...

Innerhalb dieser Methode kann man ja auf die anderen Objekte im Kreis zugreifen. Ein sicheres Entfernen setzt also voraus, dass man entscheiden kann welches Objekt das *nicht* tut und damit als erstes entfernt werden kann. Von dem pathologischen Fall das es *alle* Objekte im Kreis tun und keines sicher als erstes entfernt werden kann, mal ganz abgesehen. Diese Entscheidung kann man bei so einer dynamischen Sprache wie Python einfach nicht automatisiert entscheiden.

... aber ich hab das nicht für einen Grund angesehen der es unmöglich macht einen Mark-and-Sweep zu implementieren. Aber deine Ausführung klingt logisch, und das könnte IMO ein grund sein weshalb es in Ruby geht, da es da sowas nicht wie eine ``__del__`` Methode gibt (Nicht das ich wüsste).

Nochmals vielen dank an euch beiden, das ihr mir meine Fragen beantwortet habt.