
VIELEN DANK
Kurt
Richtig. Den opcode gibts, aber die Syntax nicht. Wenn du brav bist und lieb nachfragst gibts vielleicht einen future import für nonlocalsma hat geschrieben:Was ich mich ja schon immer gefragt habe: Python kann freien Variablen in einer Funktion keinen neuen Wert zuweisen, aber dennoch gibt es den Bytecode STORE_DEREF, der doch genau dieses machen könnte. Oder verstehe ich da etwas falsch?
so habe nun in ner Bahnhofsbuchhandlung kurz in einen O'Reilly reinschauen können und beginne das Konzept zu verstehen, der Punkt scheint zu sein das Python-Variablen per default lokal sind. Geschieht eine Zuweisung auf eine neue Variable, dann wird sie im aktuellen lokalen Namespace (Funktionsscope) angelegt, bzw. gebunden. Deswegen kann nicht schreibend auf eine Variable im closurekontext zugegriffen werden, weil eine neue lokale angelegt wird.mitsuhiko hat geschrieben:Neu binden heißt "name = wert". Damit wird name neu gebunden. Und ja, ints sind Objekte vom typ int. In Python ist alles ein Objekt.Was heißt hier neu binden ? Ints sind in Py keine Primitiva sondern eine Art Objekt ???
Du ich kennen so manche Sprache, default local, sodass man nicht mehr schreibend auf nonlocal zugreifen kann, hab ich noch nie gesehen und ist IMHO der Erwähnung Wert.mitsuhiko hat geschrieben: Im übrigen darfst du nicht mit deiner Vorstellung von Perl auf Python zurennen weil das überaus schmerzhaft wird.
Code: Alles auswählen
javascript:
var b=["B"];
var a=["A"];
a[1]=b;
b[1]=a;
alert(a[1][1][1]);
In Ruby/JavaScript lässt der Interpreter alle übergeordneten Frames im Speicher, selbst wenn die Variablen dort nicht genutzt werden. In Python erkennt der Intepreter, welche Variablen tatsächlich referenziert werden und nur diese bleiben in den cell-vars gespeichert. Wenn du nicht auf self zugreifst stirbt dann zb die Klasse.Kurt Z hat geschrieben:Allerdings verstehe ich die Kausalität zwischen Memory Leaks und Blockscopes immer noch nicht.
Code: Alles auswählen
>>> class Foo(object):
... def make_closure(self, num):
... return lambda: num
...
>>> foo = Foo()
>>> funcs = map(foo.make_closure, range(10))
>>> sys.getrefcount(foo)
2
Dies ist so falsch bzw. nur richtig für reference counting, was kein echter garbage collection Algorithmus ist. Diese (z.B. die Klassiker stop© oder mark&sweep) haben mit Ringbezügen keine Probleme.Memoryleaks entstehen meines Wissens wenn die Garbage Collection eine Variable nicht entsorgen kann, weil die Variable nur anscheinend noch gebraucht wird. Z.B. bei Ringbezügen
Sowas z.B. http://developers.slashdot.org/article. ... 17/0552247Y0Gi hat geschrieben:Speicherlecks entstehen meines Wissens, wenn ein Progammierer unabsichtlich Referenzen auf Objekte belässt und davon ausgeht, wieder eine saubere Ausgangslage für den nächsten Schritt zu haben. Das gilt sowohl für Implementierungen von Programmiersprachen als auch Programmen selbst.