Ich bekomme es ohne eval nicht hin

[Alfons Mittelmeyer]

(...) also warum man nun kompilierten Code aus vielen solchen Pythonprogrammen nun unbedingt dauerhaft bis zum Beenden von Python als globale Variablen im Hauptspeicher sammeln will.

Das will man selbstverständlich nicht. Daher nutzt man ja auch lokale Variablen, verwendet ggf Datenstrukturen wie Stacks oder Warteschlangen, usw. Aber man nutzt dafür eben nicht `del`!

Ja genau um das geht es. Wenn man in den Genuss lokaler Variablen kommen will, muss man dafür eine Funktion definieren. Aber wenn man eine Funktion definiert hat, nur für den Zweck lokale Variablen benützen zu können und die Funktion sonst keinen Zweck erfüllt. Ja warum soll ich sie dann nach Ausführung nicht als Waste deklarieren?

Und wenn Du meinst, dass man dafür nicht del benutzt, dann sage mir bitte, welche Funktion man dafür sonst benutzt!
Außerdem kannst Du mir ja auch vielleicht sagen, für welchen Zweck die Python Core Entwickler del vorgesehen haben. Also was ist der Zweck von del. Denn ohne Zweck programmiert man keine derartige Funktionalität.

[Sirius3]

dann genügt ein del für die Instanz und ein del für die Klasse

Instanzen brauchen gar kein del, weil die automatisch abgeräumt werden, wenn sie nicht mehr gebraucht werden. Für Klassen sieht das anders aus. Bisher konntest Du noch keine konkrete Anwendung für Deinen Fall, dass ständig irgendetwas nachgeladen wird, liefern. Selbst bei 500 Klassen fällt der Speicher für den Code nicht weiter ins Gewicht und das ist schon eine sehr große Anwendung. 99% der Desktop-Anwendungen werden spätestens am Abend beendet, 99% der Server-Anwendungen nach wenigen Minuten. Daher frage ich Dich ernsthaft, hast Du eine konkrete Anwendung im Sinn? Ist der Code in diesem Fall wirklich ein Problem? Stört es Dich, dass Microsoft-Word ein Funktion für japanische Datumsangaben hat, obwohl Du sie noch nie benutzt hast?

[pillmuncher]

Also was ist der Zweck von del.

Guckstu:

Code: Alles auswählen

In [1]: seq = list('hallo')

In [2]: seq
Out[2]: ['h', 'a', 'l', 'l', 'o']

In [3]: del seq[1]

In [4]: seq
Out[4]: ['h', 'l', 'l', 'o']

In [5]: del seq[1:3]

In [6]: seq
Out[6]: ['h', 'o']

In [7]: dic = dict(a=1, b=2, c=3)

In [8]: dic
Out[8]: {'a': 1, 'b': 2, 'c': 3}

In [9]: del dic['b']

In [10]: dic
Out[10]: {'a': 1, 'c': 3}

In [11]: class C:
   ....:     def __init__(self):
   ....:         self.x = 123
   ....:

In [12]: c = C()

In [13]: c.x
Out[13]: 123

In [14]: del c.x

In [15]: c.x
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-15-1f89b44c0846> in <module>()
----> 1 c.x

AttributeError: 'C' object has no attribute 'x'

In [16]: y = 456

In [17]: y
Out[17]: 456

In [18]: z = y

In [19]: del y

In [20]: y
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call last)
<ipython-input-20-009520053b00> in <module>()
----> 1 y

NameError: name 'y' is not defined

In [21]: z
Out[21]: 456

Insbesondere die letzten beiden Zeilen sollten klarmachen, dass del zur manuellen Speicherverwaltung völlig ungeeignet ist.

[jens]

99% der Server-Anwendungen nach wenigen Minuten.

Das stimmt nicht. Meine fcgi Prozesse laufen mitunter Stunden und machmal auch Tagelang... Doch der Speicher läuft nicht voll und ich nutzte kein del

@Alfons Mittelmeyer: "Dynamisch nachladen" ist doch kein problem. Du packst das ganze einfach in einen geeigneten Namensraum, der dann einfach weggeschmissen wird und der gc wird dann irgendwann aufräumen.
Dumm wäre es natürlich du importierst wahllos alles in den globalen Namensraum. Aber das wäre eh nicht gut, weil du dann schnell mit Namenskonflikten zu tun haben wirst!

Wie ich schon geschrieben habe, schau dir bestehende GUI-Designer an, welche Lösungen die vornehmen. Kannst da ja auch untersuchen, ob die ein Speicherleck haben...

[Alfons Mittelmeyer]

dann genügt ein del für die Instanz und ein del für die Klasse

Instanzen brauchen gar kein del, weil die automatisch abgeräumt werden, wenn sie nicht mehr gebraucht werden. Für Klassen sieht das anders aus.

Das denkst aber auch nur Du, dass da irgendetwas automatisch geht. Der Programmierer muß mitteilen, dass die Instanzen nicht mehr gebraucht werden, wenn er etwa einen Button löscht. Dafür gibt es die Methode destroy. Wenn der Buttun sich allerdings in einem Toplevel Window befindet, braucht der Programmierer nichts mitteilen, denn wenn der User dieses Window schließt, geschieht ein destroy nicht nur für das TopLevel sondern von tkinter her auch für die Childs. Aber auch das ist nichts automatisches von Python, sondern hat man so für tkinter implementiert.

Und wenn ein Callback für einen Button definiert ist, wird der Referenzzähler um eins runtergezählt für den Callback, wenn man den Button löscht. Wenn Du allerdings eine globale Funktion dafür definiert hast und diese nicht beseitigen willst durch del, welches den Namen aus dem globalen Namensraum beseitigt und auch noch mal den Referenzzähler um eins heruntersetzt, dann bleibt das im Speicher. Wenn der Callback allerdings infolge Aufruf einer Funktion sozusagen lokal definiert wurde, dann brauchst Du Dich um nichts zu kümmern. Doch um das, was global definiert ist, muss man sich selber kümmern, wenn man Python nicht beenden will.

[Alfons Mittelmeyer]

99% der Server-Anwendungen nach wenigen Minuten.

Das stimmt nicht. Meine fcgi Prozesse laufen mitunter Stunden und machmal auch Tagelang... Doch der Speicher läuft nicht voll und ich nutzte kein del

@Alfons Mittelmeyer: "Dynamisch nachladen" ist doch kein problem. Du packst das ganze einfach in einen geeigneten Namensraum, der dann einfach weggeschmissen wird und der gc wird dann irgendwann aufräumen.
Dumm wäre es natürlich du importierst wahllos alles in den globalen Namensraum. Aber das wäre eh nicht gut, weil du dann schnell mit Namenskonflikten zu tun haben wirst!

Wie ich schon geschrieben habe, schau dir bestehende GUI-Designer an, welche Lösungen die vornehmen. Kannst da ja auch untersuchen, ob die ein Speicherleck haben...

Wäre auch eine Lösung, also alles importieren jeweils in ein und dasselbe Modul und dann immer wieder ein imp.reload machen. Kann ja mal schauen ob es klappt. Außerdem, um den GuiDesigner geht es hier jetzt nicht sondern um ein allgemeines Konzept für dynamisch unbegrenzt nachladen.

[Hyperion]

Ich werfe mal dieses hier rein: http://bugs.python.org/issue9072

Ok, 5 Jahre sind jetzt um, aber ich würde da jetzt nichts erwarten

[jens]

Wäre auch eine Lösung, also alles importieren jeweils in ein und dasselbe Modul und dann immer wieder ein imp.reload machen. Kann ja mal schauen ob es klappt. Außerdem, um den GuiDesigner geht es hier jetzt nicht sondern um ein allgemeines Konzept für dynamisch unbegrenzt nachladen.

Das hatte ich nicht im Sinn... Aber egal: "dynamisch unbegrenzt nachladen" ist wieder so ein unrealistisches worst-case Szenario ...

[Alfons Mittelmeyer]

Also Module machen keinen Sinn, denn es ist genau dasselbe der Fall (und außerdem wird es komplizierter, die auszuführende Datei vorher noch umzukopieren):

When a module is reloaded, its dictionary (containing the module’s global variables) is retained. Redefinitions of names will override the old definitions, so this is generally not a problem. If the new version of a module does not define a name that was defined by the old version, the old definition remains.

Und empfohlen wird es auch nicht gerade:

It is legal though generally not very useful to reload built-in or dynamically loaded modules, except for sys, __main__ and __builtin__. In many cases, however, extension modules are not designed to be initialized more than once, and may fail in arbitrary ways when reloaded.

Quelle: https://docs.python.org/3.1/library/imp.html

Und wie gesagt, es handelt sich nicht um Module, auf die man zugreifen will, sondern auf Anwendungen, auf die kein Modul zugreifen will, sondern nur umgekehrt.

[Alfons Mittelmeyer]

Also was ist der Zweck von del.

Insbesondere die letzten beiden Zeilen sollten klarmachen, dass del zur manuellen Speicherverwaltung völlig ungeeignet ist.

Ja toll, del soll ganz am Ende gemacht werden, wo definitiv das Programm zuende ist, und nicht mittendrin, wenn man die Variablen noch braucht.

[DasIch]

eval() und exec leaken sehr leicht Referenzen.

Code: Alles auswählen

>>> eval(compile('foo = 1', '<string>', 'exec'))
>>> foo
1

Dadurch lassen sich sehr leicht Memory Leaks produzieren

Wo wir übrigens bei Memory Leaks sind, folgendes als "foo.py" speichern:

Code: Alles auswählen

class Foo(object):
    def __del__(self):
        print 'Collected'


f = Foo()

Code: Alles auswählen

λ python foo.py 
Collected

λ python
Python 2.7.10 (default, Jun  3 2015, 19:28:03) 
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.49)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import gc
>>> for _ in range(10):
...  execfile('foo.py', {})
...  print gc.collect(), len(gc.garbage)
... 
9 1
9 2
9 3
9 4
9 5
9 6
9 7
9 8
9 9
9 10

So schnell haben wir ein Memory Leak mit exec was wir ohne gar nicht hätten.

Dazu kommen dann noch Probleme bei statischer Analyse, Debugging und Dokumentation die das Leben spannender machen. Die Kombination von Code der Introspektion betreibt und eval/exec dürfte auch zu Probleme führen. Von Performance dürfte man sich auch verabschieden können.

Wie kommt man eigentlich auf die Idee dass der Source Code in Form von Strings weniger Speicher verbraucht, als der equivalente Code in Form eines importiertem Moduls?

[Alfons Mittelmeyer]

eval() und exec leaken sehr leicht Referenzen.
So schnell haben wir ein Memory Leak mit exec was wir ohne gar nicht hätten.

Dazu kommen dann noch Probleme bei statischer Analyse, Debugging und Dokumentation die das Leben spannender machen. Die Kombination von Code der Introspektion betreibt und eval/exec dürfte auch zu Probleme führen. Von Performance dürfte man sich auch verabschieden können

Das schreibe ich ja die ganze Zeit, ich habe das selber getestet und wenn man del verwendet, gibt es kein Memory Leak, also del F und del Foo fehlen hier.

Und über del habe ich ausser Vermutungen und uninteressante Fälle fast nichts im Internet gefunden. Aber hier ist es einmal richtig beschrieben, wenn Ihr mir schon nicht glauben wollt, dann ist hier noch eine Quelle:

The reason del foo doesn't work is also simple to explain. I initially confused myself by thinking that del foo would call the destructor, but it only decreases the reference counter on the object (and removes the reference from the local scope). Since the count in the code above for Foo and Bar is 2 (one in the main program, one in the other instances), the count will only go down to 1 for the object

Quelle: http://www.electricmonk.nl/log/2008/07/ ... ion-notes/

Also Referenzzähler eins runter und Namen aus Namespace entfernen. Und damit erklärt man ein Objekt, auf das nur der Name verweist und nichts anderes als Waste.

Ach sorry, das mit dem Beweis hatte ich im tkinter Forum beschrieben und nicht hier. Hatte ein Testprogramm mit Funktionen dynamisch erzeugen und ausführen. Ohne del Crash nach ein paar Minuten mit del ohne Probleme auch am nächsten Morgen.

Und Anwendungsfälle gibt es genug. Hier handelt es sich um das Top-level script environment:

'__main__' is the name of the scope in which top-level code executes. A module’s __name__ is set equal to '__main__' when read from standard input, a script, or from an interactive prompt

Quelle: https://docs.python.org/3/library/__main__.html

Und viele starten nicht immer python neu, sondern beschicken python über den standardinput mit unterschiedlichsten Scripten. Und auch da kann es bei unterschiedlichsten Scripten und längerer Laufzeit dann zu Memoryleaks und Crashs kommen, wenn man den globalen Müll der Scripte nicht mit del beseitigt.

[Sirius3]

@Alfons Mittelmeyer: das ist Dein Problem, dass Du irgendwelchen dubiosen Quellen aus dem Internet vertraust. Die wirklich verlässliche Quelle ist die Python-Dokumentation:

Deletion of a name removes the binding of that name from the local or global namespace

Hier ist nicht von Referenzen die Rede. Hier geht es nur um Namen. Ist der entsprechende Name noch im Namespace oder nicht. "del" hat also erst einmal nichts mit Speichermanagement zu tun.

[pillmuncher]

Also was ist der Zweck von del.

Insbesondere die letzten beiden Zeilen sollten klarmachen, dass del zur manuellen Speicherverwaltung völlig ungeeignet ist.

Ja toll, del soll ganz am Ende gemacht werden, wo definitiv das Programm zuende ist, und nicht mittendrin, wenn man die Variablen noch braucht.

Nein, Du hast es immer noch nicht begriffen.

del löscht keine Objekte aus dem Speicher, sondern macht eines von zwei Dingen.

Erstens: bei einer Collection, die den Subscriptions-Operator (d.h. z.B. foo[bar]) implementiert, kann man mit del Elemente aus der Collection entfernen. Ob das entfernte Objekt dann vom Garbage Collector aufgeräumt werden kann, hängt davon ab, ob es keine anderen Verweise auf dieses Objekt gibt.

Zweitens: in allen anderen Fällen löscht man mit del einen Namen aus einem Namespace, wodurch natürlich die Assoziation des Names mit dem Objekt, auf das er verweist, ebenfalls gelöst wird. Nun können viele Namen gleichzeitig auf dasselbe Objekt verweisen und ein Objekt wird frühestens vom Garbage Collector aufgeräumt, wenn keine Verweise (durch Namen, aber auch namelose Verweise aus Collections heraus) darauf mehr existieren. Auch dann ist aber nicht garantiert, dass ein verwaistes Objekt jemals aufgeräumt wird, zB. gibt es (seltene) Fälle, wo das Vorhandensein einer __del__() Methode den GC beim Aufräumen behindert.

So, wie ich es sehe, möchtest du einfach nicht in einer Sprache mit Garbage Collector arbeiten, sondern Speicher lieber manuell verwalten. Dann ist Python die falsche Sprache.

[jens]

Und viele starten nicht immer python neu, sondern beschicken python über den standardinput mit unterschiedlichsten Scripten.

Ach ja?
Welche Beispiele kannst du da nennen?
Und in welche hilft del?

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: das ist Dein Problem, dass Du irgendwelchen dubiosen Quellen aus dem Internet vertraust. Die wirklich verlässliche Quelle ist die Python-Dokumentation:

Deletion of a name removes the binding of that name from the local or global namespace

Hier ist nicht von Referenzen die Rede. Hier geht es nur um Namen. Ist der entsprechende Name noch im Namespace oder nicht. "del" hat also erst einmal nichts mit Speichermanagement zu tun.

Ja denkst Du dass Dokumentationen so etwas wie die Bibel sind? Entweder die Autoren wissen es selber nicht genau oder sie vergessen das auch zu schreiben oder sie geben sich nicht die Mühe auch die Details zu beschreiben.
Das ist eben so. Was in Dokumentationen steht, stimmt. Aber manchmal steht eben nur die Hälfte drin. Daher kann man keinerlei Dokumentationen ernstlich als verläßliche Quellen für das was nicht drin steht, gebrauchen.

Und das ist eben ein Fakt, der nicht in der Doku steht:

decreases the reference counter on the object

Und da hilft keine Diskussion, sondern selber testen. Oder ihr fragt die Python Core Entwickler

Und warum, weiß ich dass man das so implementiert? Weil es etwa auch in .Net so implementiert ist, und weil ich das genauso implementiert habe. Und alles andere Unsinn ist.

Also wenn man ein Objekt definiert, dann geht der Referenzähler zuerst mal auf eins. Wenn man ein globales Objekt anschließend mit del löscht, dann soll es aus dem Namensraum beseitigt werden aber der Referenzzähler auf eins bleiben? Sozusagen zugriffsloser dauerhafter Müll? Wie kann man nur so einen Blödsinn glauben?

[Sirius3]

@Alfons Mittelmeyer: In Python ist die Speicherverwaltung nicht spezifiziert. Also kann man auch keine Aussagen darüber treffen. An die Spezifikation muß sich jede Python-Implementierung halten, was nicht drin steht, darauf kann sich kein Programmierer verlassen.

Und Dein unsägliches Crash-Beispiel, ohne del zu benutzen:

Code: Alles auswählen

from itertools import count

for i in count():
    namespace = {}
    func_str = ("def function{0}(): print 'This is function {0}'\n"
                "function{0}()").format(i)
    exec(func_str, namespace)

Was aber nicht bedeuten soll, dass man so ein Konstrukt einsetzen sollte.

[BlackJack]

@Alfons Mittelmeyer: ``del`` ganz am Ende macht keinen Sinn weil dann ja das Programm zuende ist und sowieso alles abgeräumt wird. Wenn man beliebige Python-Anwendungen aus einer Python-Anwendung heraus starten will, dann nimmt man dafür Prozesse. Und schon hat man kein Problem mehr das man die Anwendungen irgendwie speziell schreiben muss, damit am Ende davon nichts im Speicher bleibt. Das ist eine ganz einfache Lösung die auch tatsächlich funktioniert, egal welche Sonderfälle es in der Python-Implementierung bei Garbage gibt und egal welche Methode für die Speicherbereinigung tatsächlich benutzt wird.

Wer beschickt Python über stdin mit unterschiedlichen Skripten? Beispiele? Also Mehrzahl, denn wenn es viele sind… (Und bitte nichts selbst ausgedachtes, sondern reale Beispiele.)

Dein Testprogramm ist kein Beweis, denn das Verhalten welches Du dort siehst ist von der Sprache Python nicht garantiert.

Über Referenzen steht nichts in der Dokumentation weil die nicht garantiert sind. Die Sprachspezifikation kennt keine Referenzzähler und eine Python-Implementierung muss keine verwenden und es gibt Implementierungen die auch *tatsächlich* keine Verwenden, da stimmen Deine Annahmen über ``del`` dann nicht. Die JVM und damit Jython verwenden zum Beispiel keine Referenzzähler. Alle Sprachen die auf der JVM laufen sind also Unsinn? Da könnte man dann wahrscheinlich keine Serversoftware mit laufen lassen. Oh warte, das machen aber viele…

Selbst in CPython kann es Objekte geben deren Referenzzähler am Ende nicht auf 0 steht, die aber trotzdem Garbage sind, man den Zähler also nicht mehr mit ``del`` verringern kann. *Und* dann kann es sogar sein, dass solche Objekte nie freigegeben werden (können), also erst mit Prozessende freigegeben werden. Und selbst wenn man alles freigeben würde, so wie Du das versuchst, wie es aber nicht garantiert geht, könnte das Programm am Ende wegen Speicherfragmentierung vielleicht doch an Speichermangel sterben, weil zwar genug Speicher da ist, aber keiner in ausreichender Menge *am Stück*. Das kann man alles umgehen in dem man die unabhängigen Anwendungen aus Deinem realitätsfernen Szenario als Prozesse starten würde.

[Hyperion]

Daher kann man keinerlei Dokumentationen ernstlich als verläßliche Quellen für das was nicht drin steht, gebrauchen.

Öh... Du bist also auch so ein Verfechter amerikanischer Mentalität, bei der man *explizit* alles evtl. mit einer Sache mögliche a priori benennen und vor der Zweckentfremdung warnen muss?

("Ein Tempomat ist kein Autopilot und kann nicht lenken!" )

Und warum, weiß ich dass man das so implementiert? Weil es etwa auch in .Net so implementiert ist, und weil ich das genauso implementiert habe. Und alles andere Unsinn ist.

Du weißt also Dinge besser als die Python Entwickler? Du hast in den CPython-Quellcode geguckt? (und ggf. in alle anderen, damit Du weißt, wie sich die angebliche Magie hinter ``del`` in anderen Implementierungen verhält?

Und was meinst Du mit .NET? Vermutlich die CLR? Aber inwiefern gibt es zwischen dieser und einem Statement in einer bestimmten Sprache einen Zusammenhang? Oder gehörst Du zu solchen komischen Menschen, die in C# einen Destruktor implemenieren? (Wie im Buch C# in 21 Tagen von 2008 gezeigt und empfohlen ) Oder was meinst Du damit?

Und was hast Du "genauso" implementiert?

So langsam wird's echt lächerlich... so wenig Selbstreflektion kann man doch kaum haben, wenn der Intellekt zumindest so weit reicht, dass man sich in halbwegs komplexe Programmierprobleme einarbeiten kann. Komisch, da sehe ich eine große Diskrepanz der mentalen Kompetenzen... aber meine Hinweise bezüglich "gegen den Strom schwimmen" ignorierst Du ja auch konsequent

[Alfons Mittelmeyer]

Also, diese ganze Diskussion geht mir jetzt langsam auf den Geist. Wißt Ihr was ich da mache? Ich schreibe einfach eine Funktion delAll() und lösch nach der Ausführung eines Scripts einfach alles raus, ohne dass ich da mit Leuten, die eine skurrile Auffassung haben über das, was del macht, lange darüber diskutiere.

Einfache Lösung, oder?