Ich bekomme es ohne eval nicht hin

[Sirius3]

@Alfons Mittelmeyer: Du wirst wohl keim die Core-Entwickler mit Deinen Ideen überzeugen können. Kannst Du mal alles in einen großen Rahmen setzen, was Du machen möchtest. Du willst einen GUI-Editor bauen, der welche speziellen Features hat? Und wie hast Du Dir vorgestellt, dieses oder jenes Feature umzusetzen?

[Alfons Mittelmeyer]

Die letzte Zeile ist Unsinn und `eval()`/`compile()` sind nicht die Lösung sondern eine Funktione zu schreiben. Und Du weisst das diese Antwort kommt, also könntest Du bitte aufhören zu trollen…

Also mit dem Quatsch dass del Unsinn ist, sollte man auch aufhören, wenn man nicht kapiert hat, was del macht.

Über Dateilöschen erzählt ihr ja auch nicht so einen Blödsinn, dass das absolut unsinnig wäre, weil dadurch ja nicht die Daten im jeweiligen Block auf der Festplattte gleich verschwinden. Und das Verhalten wäre absolut unvorhersehbar, weil es nicht vorhersehbar wäre, wann jetzt im betreffenden Block die Daten überschrieben würden und wer weiß ob das überhaupt jemals geschieht. Da sieht man, dass File Löschen erstens, da unbestimmt, gar keinen Sinn macht. Und dann macht es auch gar keinen Sinn, weil man ja sowieso eine große Festplatte hat.

Wenn Ihr derartige Argumente in Bezug auf del bringt, was will man da auch noch diskutieren. Da ist dann Hopfen und Malz völlig verloren.

[Sirius3]

@Alfons Mittelmeyer: Dein Vergleich mit einer Festplatte hinkt. Du betreibst del als Mikromanagement, und Mikromanagement ist unsinnig und damit del auch.

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: Du wirst wohl keim die Core-Entwickler mit Deinen Ideen überzeugen können. Kannst Du mal alles in einen großen Rahmen setzen, was Du machen möchtest. Du willst einen GUI-Editor bauen, der welche speziellen Features hat? Und wie hast Du Dir vorgestellt, dieses oder jenes Feature umzusetzen?

Gui Editor ist klar, um den soll es jetzt mal nicht gehen, sondern ein allgemeines Konzept für:

Bei beschränktem Vorhandensein von Python Modulen- die Anwendungen müssen eben mit einer vorgegebenen Modulsammlung auskommen - unbeschränkt Pythonanwendungen aufrufen aber nicht mit Python Neustart, sondern während Python läuft.

Wofür das Konzept gebraucht wird, nämlich wieder für eine allgemeine Lösung:
Das Starten von Pythonprogrammen geschieht über eine GUI und die gestarteten Anwendungen sollen in einem GUI Fenster laufen, welches nicht von der jeweiligen Anwendung bestimmt wird, sondern von der HauptGui. Diese Anwendungen können völlig autark sein. Jedoch kann es auch vorkommen, dass eine Anwendung in einem Fenster der HauptGui - so etwas wie eine Fensterverwaltung - mit einer andern Anwendung in einem anderen Fenster kommuniziert und damit ein größeres funktionelles Ganzes bildet.

Außerdem kann es auch vorkommen, dass Anwendungen in einem Fenster der GUI am laufenden Band ausgetauscht werden, wobei auch direkt wie Fließband vorstellbar wäre. Und im Falle von wie Fließband wäre ohne die Benützung von del in kurzer Zeit mit einem Crash des Gesamtprogrammmes zu rechnen, das habe ich schon getestet, sowie dass es mit del keinen Crash gab.

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: Dein Vergleich mit einer Festplatte hinkt. Du betreibst del als Mikromanagement, und Mikromanagement ist unsinnig und damit del auch.

Ich möchte wissen, was da mikro sein soll, wenn man eine Python Hauptanwendungen entlädt. Es könnten Anwendungen von zehntausend Zeilen Source sein - und zwar viele Anwendungen - auch wie am Fließband - unbeschränkt. Warum man jetzt kompilerten Hauptprogramm Code, wovon es aber jetzt ständig neu nachgeladene Hauptprogramme geben soll - , 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.

Und da sagt Ihr doch, dass man möglichst keine globalen Variablen verwenden soll. Also del hat da nichts mit mikro zu tun, das ist hier makro.

Also, dass man den Code aller dynamisch aufgerufenen Python Programme im Haupspeicher als globale Variablen speichert, ist ausgemachter Unsinn. Programme sammelt man auf der Festplatte aber sammelt nicht alle Programme nach Aufruf im Hauptspeicher. Prinzip: nach Programmende - den vom Programm verwendeten Hauptspeicher wieder freigeben. Ansonsten baldiger Crash, wenn man das nicht so macht. Komisch, dass Ihr das nicht kapiert.

[BlackJack]

Also mit dem Quatsch dass del Unsinn ist, sollte man auch aufhören, wenn man nicht kapiert hat, was del macht.

*Du* hast nicht verstanden wofür ``del`` gedacht ist und welche Garantien die Sprachspezifikation zum Thema Speicherverwaltung gibt und welche eben nicht, und deshalb ``del`` für manuelle Speicherverwaltung nicht gedacht weil nicht geeignet ist. Und mehr brauchst *Du* dazu jetzt auch nicht mehr zu schreiben. Das andere Thema ist ja nicht aus Spass geschlossen worden, sondern weil die Diskussion angefangen hat Leute zu nerven.

[Hyperion]

Also mit dem Quatsch dass del Unsinn ist, sollte man auch aufhören, wenn man nicht kapiert hat, was del macht.

Offenbar hast Du ja nicht verstanden, was ``del`` macht, denn sonst würdest Du es nicht für einen Zweck einsetzen, für den es nicht gemacht ist.

Ich hatte Dir schon einmal etwas bezüglich gegen den Strom schwimmen gesagt, was ich hiermit noch erweiternd auf konkrete Technologien - in diesem Falle Python - beziehen möchte: Du willst nicht die offensichtlichen Konzepte zur Lösung eines Problems heran ziehen, sondern suchst entgegen aller Ratschläge nach einer Lösung, die offenbar durch die Sprachmittel *nicht* einfach und / oder nicht zuverlässig umzusetzen ist. Du arbeitest damit gegen die Sprache und nicht mit ihr. Das ist beim Programmieren immer schlecht und allgemein bei so ziemlich allen Technologien, die man zweck entfremdet benutzt.

Die Frage bleibt also: Wieso tust Du das? Wieso suchst Du Dir nicht ein Werkzeug, welches Deinen Vorstellungen eher entspricht? Das würde Dein Leben (und unseres) deutlich vereinfachen und am Ende könnte dann auch etwas brauchbares herauskommen

[Sirius3]

@Alfons Mittelmeyer: geh doch mal wieder vom Allgemeinen zum Konkreten, welche Anwendung hast Du im Sinn, die ständig andere Anwendungen nachlädt? Was soll die Anwendung können? Wer setzt sie wie ein? Wieviele Teile hat sie konkret? Wer oder was bewirkt, dass ein Teil nachgeladen werden muß?

[snafu]

(...) 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`!

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: geh doch mal wieder vom Allgemeinen zum Konkreten, welche Anwendung hast Du im Sinn, die ständig andere Anwendungen nachlädt? Was soll die Anwendung können? Wer setzt sie wie ein? Wieviele Teile hat sie konkret? Wer oder was bewirkt, dass ein Teil nachgeladen werden muß?

Es dürfen beliebige Python Anwendungen sein. Aber meine Anforderung an diese Anwendungen sind, dass sie nichts im globalen Speicher zurücklassen. Und dass man sich nicht auf den Standpunkt stellt: normalerweise wird dann auch Python beendet und deshalb muss ich auch nichts aufräumen. Meine Anforderung ist, dass dann auch aufgeräumt wird. Deshalb empfiehlt sich da auch eine diesem Falle angemessene Programmierung. Wenn man 50 Funktionen und 40 globale Varoiablen definiert hat und dann bei der Beendigung mit einer del Liste das alles löscht, das wäre Mikroprogrammierung und so sollte es nicht sein. Wenn man allerdings eine Klasse macht mit diesen 50 Funktionen als Memberfunktionen und die Variablen als Membervariablen, dann genügt ein del für die Instanz und ein del für die Klasse. Was natürlich noch besser wäre, wäre eine Python Funktion, die den globalen Speicher der Anwendung - nicht den der Module - bereinigt. Dann müßten die Anwendungen keine besondere Anforderungen erfüllen.

Und so sollten Anwendungen programmiert sein, die dynamisch nachgeladen werden. Das ist meine Anforderung an solche Anwendungen. Ich habe allgemein eine Anwendung im Sinn, die dynamisch andere Anwendungen lädt und startet, ohne dass Python beendet wird, ist das schwer zu begreifen? Und dass dann abends Python beendet wird, gehört auch nicht zu den Randbedingungen. Es soll auch jahrelang laufen können. Natürlich im Falle eines Kills müßte dieser Service wieder hochgefahren werden, was man aber automatisch tun könnte. Aber laufend Kills wegen Speicherzumüllung will ich nicht haben.

[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.