'command' zwei Argumente übergeben?

[Sirius3]

@Alfons Mittelmeyer: ist das jetzt eine ernst gemeinte Frage oder willst Du mit Deinem Fettdruck nur ausdrücken, dass hier alle außer Dir keine Ahnung von Programmieren um Allgemeinen und von Python im Speziellen haben?

Nimm einfach ein paar Sachen als gegeben an:
- der Programmcode von Modulen und Funktionen existiert so lange das Programm läuft.
- in dem man keine globalen Variablen benutzt, hat man schon den ersten Schritt geschafft, dass Daten nur so lange im Speicher sind, wie sie gebraucht werden
- beherzige YAGNI

[jens]

@Alfons Mittelmeyer: Du machst dir weiterhin Gedanken über Probleme, die du noch gar nicht hast. Du bist echt Beratungsresistent So langsam könnte man auf die Idee kommen, das du einfach nur Trollen willst...

- beherzige YAGNI

Kannte ich noch gar nicht. Passt auch gut zu KISS

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: ist das jetzt eine ernst gemeinte Frage oder willst Du mit Deinem Fettdruck nur ausdrücken, dass hier alle außer Dir keine Ahnung von Programmieren um Allgemeinen und von Python im Speziellen haben?

Nimm einfach ein paar Sachen als gegeben an:
- der Programmcode von Modulen und Funktionen existiert so lange das Programm läuft.
- in dem man keine globalen Variablen benutzt, hat man schon den ersten Schritt geschafft, dass Daten nur so lange im Speicher sind, wie sie gebraucht werden
- beherzige YAGNI

Sorry Sirius3, das will ich nicht ausdrücken. Aber Snafu hatte vorher auch schon einen Unsinn behauptet und BlackJack ebenso und jetzt hat snafu schon wieder Unsinn behauptet. Und das was Du jetzt schreibst, muss ich auch nicht als gegeben annehmen, denn das ist Grundwissen.

Aber exakt Du es nicht formuliert. So sieht es fast eher nach Hallbwissen aus.

- der Programmcode von Modulen und Funktionen existiert so lange das Programm läuft.

Also der Programmmcode befindet sich in Files .py oder .pyc und existiert daher auch länger. Beim ersten import wird der Programmcode abgearbeitet und bleibt nicht im Speicher. Im Speicher bleiben die vom Programmcode definierten globalen Strukturen, wie Klassen, Variablen und Funktionen. Wenn man in einem anderen Modul wieder einen import macht, geschieht nichts, ausser dass man dann Zugriff auf diese Funktionen Variablen usw. hat.

Im Falle von Funktionen ist der Programmcode nicht die Funktionen, sondern die Definiton der Funktionen. Nach diesen Definitionen kann man den Programmcode vergessen. Es gibt auch Module, die selber keine Funktionen etc. definieren, sondern lediglich die Werte von bereits vorhandenen globalen Strukturen ändern. Da sie selber keine globalen Definitionen enthalten, könnte man sie auch lokal in einer Funktion verpackt ablaufen lassen. Das könnte man etwa mit einer tkinter Anwendung machen. Der Vorteil wären dann lokale Variablen, lokale sonstige Namen, Defaultwerte durch lokale Variablen ausgedrückt.

Wenn man allerdings so eine Anwendung, die man importiert - beim GuiCreator waren es vor der Aufteilung in Module etwa 3000 Zeilen - jetzt in eine Funktion verpackt, indem man den Code einrückt und def buildGui(): drüberschreibt, dann muß einem bewußt sein, dass dadurch nicht nur tkinter Strukturen belegt werden, sondern man auch diese Funktion im Speicher hat. Normalerweise hätte man sie gar nicht gebraucht, sondern einfach das Modul importiert. Aber wegen dem Vorteil lokaler Namen hat man das Modul mit einer Funktion umgeben.

Und wenn man das dann importiert hat, hat man nicht dasselbe wie zuvor. Importieren alleine genügt nun nicht mehr, sondern man muss danach diese Funktion aufrufen. Und noch immer ist das Ergebnis nicht dasselbe wie zuvor. Man hat nämlich dann auch diese zusätzliche Funktion im Speicher, welche den ganzen Programmcode für eine Anwendung enthält. Wenn man ein ganzes Modul in eine Funktion verpackt hat, dann will man dann trotzdem dass nachher alles ist, wie zuvor, das heißt, dass man nach dem Aufruf dann diese Funktion durch del als Garbage markiert.

Ich verstehe nicht, warum man hier so einen Aufstand gegen del macht und falsche Behauptungen aufstellt, wie dass das automatisch von der Speicherverwaltung gelöscht würde.

Apropos Parameterübergabe: meine Rückruffunktionen hatten Dir bisher ja nicht gefallen. Schon mal einen einen Blick geworfen ins Threadthema "Gui-Anderung einer Eigenschaft in einem anderen Modul". Was sagst Du zu dieser Rückruffunktion?

[snafu]

Also, globale Referenzen werden beseitigt, wenn man den jeweiligen Namensraum verläßt?

Der globale Namensraum wird nicht einfach so verlassen. Daher heißt er ja auch globaler Namensraum. Ein "Verlassen" findet erst dann statt, wenn der Interpreter beendet wird (und dann gibt es auch keine Rückkehr mehr). In dem Moment wird auch `a.globvar` abgeräumt. Bis zu diesem Zeitpunkt hat man die böse, böse 5 tatsächlich dauerhaft im Speicher. Mal abgesehen davon, dass sie ohnehin im Speicher bleibt, da CPython alle kleineren Zeilen während der gesamten Interpreter-Laufzeit gecacht vorhält. `del` wird dir da also speichertechnisch rein gar nichts bringen.

Und das mit dem angeblichen Unsinn überhöre ich mal...

[jens]

Sorry Sirius3, das will ich nicht ausdrücken. Aber Snafu hatte vorher auch schon einen Unsinn behauptet und BlackJack ebenso und jetzt hat snafu schon wieder Unsinn behauptet. Und das was Du jetzt schreibst, muss ich auch nicht als gegeben annehmen, denn das ist Grundwissen.

:K

[snafu]

@jens: Er ist der Messias, welcher in geheimen Geheimtreffen Spezialinformationen von den Python-Core-Entwicklern zum Thema `del` erhalten hat, die uns bisher bewusst vorenthalten wurden. Nicht mal in der offiziellen Python-Dokumentation sind diese Informationen zu finden. Wir sollten ihm einfach Glauben schenken. Denn Glauben ist das einzige, was uns wieder auf den rechten Programmier-Pfad bringen kann.

[Alfons Mittelmeyer]

Also, globale Referenzen werden beseitigt, wenn man den jeweiligen Namensraum verläßt?

Der globale Namensraum wird nicht verlassen. Daher heißt er ja auch globaler Namensraum. Ein "Verlassen" findet statt, wenn der Interpreter beendet wird. Und dann wird auch `a.globvar` abgeräumt. Bis zu diesem Zeitpunkt hat man die böse, böse 5 tatsächlich dauerhaft im Speicher. Mal abgesehen davon, dass sie ohnehin im Speicher bleibt, da CPython alle kleineren Zeilen während der gesamten Interpreter-Laufzeit gecacht vorhält. `del` wird dir da also speichertechnisch rein gar nichts bringen.

Und das mit dem angeblichen Unsinn überhöre ich mal...

Also schon mal besser. Und ob alle kleineren Zeilen dauerhaft im Speicher bleiben? Der Test ergab, dass es nicht so ist. Die kleineren Zeile, sind die Zeilen, die am längsten im Speicher bleiben. Aber wenn es eng wird, kommen auch diese dran. Der Test war diese Funktion variabel hochgezählt:

Code: Alles auswählen

def function1000000():
	print "function1000000: This isn't much, normally it should be a GUI"

Bei meinem kleinen Computer mit nur 1GB - ein Android TV Stick umgebrannt auf Linux picuntu, ohne del crash nach ein paar Minuten bei 698000.
Mit del auch nach der ganzen Nacht mit über 15.000.000 noch kein Crash und ich konnte mit dem Computer sogar noch dabei arbeiten.

Und wie gesagt, um die kleineren Zeilen geht es mir auch nicht, sondern um größere Anwendungen. Das mit den kleinen Zeilen war nur ein Test, hoffentlich mal kapiert.

Vielleicht hast Du gemeint, dass alle kleineren Zeilen, die kein Garbage sind, dauerhaft gecasht bleiben? Garbage währen der gsamten Laufzeit dauerhaft zu cashen, wer würde denn so etwas programmieren?

[jens]

@Alfons Mittelmeyer: Du machst dir weiterhin Gedanken über Probleme, die du noch gar nicht hast. Du bist echt Beratungsresistent

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: Du machst dir weiterhin Gedanken über Probleme, die du noch gar nicht hast. Du bist echt Beratungsresistent

Jens Du machst Dir weiterhin Gedanken um Probleme die gar keine sind. Eine Programmierer sollte Programme schreiben und nicht tagelang darüber nachdenken, ob er jetzt del nehmen soll oder es vielleicht doch nicht braucht, da sein Computer ja 8GB Speicher hat und er ihn abends wieder ausschaltet und daher ruhig in den Speicher müllen kann. Ohne die Randbedingungen und die Endanwendungen zu kennen, kann so eine Frage nicht entschieden werden. Wenn eine Endanwendung auf einem Gerät mit 40 MB laufen würde und das Gerät monatelang nicht ausgeschaltet würde, hätte man laufend einen Crash. Der Grundsatz guter Programmierung heißt einfach, dynamisch allokierten Speicher, den man nur vorübergehend braucht, immer nach Gebrauch wieder freigeben und nicht das nächste mal wieder neu allokieren, bis kein Speicher mehr übrig ist. Du möchtest schließlich auch nicht mit einem Flugzeug abstürzen oder einen Autounfall haben, weil jemand den Speicher vollgemüllt hat.

Also da kannst Du mich noch soviel "beraten" wollen, wie Du es nennst. Aber so heißt mein Grundsatz, und davon weiche ich nicht ab. Und mich von etwas anderem überzeugen zu wollen. Dagegen bin ich wirklich resistent.

Wenn Du Programme anschauen willst, dann schau Dir lieber mal meinen neuen Callback im Thread "Gui-Anderung einer Eigenschaft in einem anderen Modul". Darüber können wir gerne weiter diskutieren.

[snafu]

Ich sprach nicht von kleineren Zeilen, sondern von kleinen *Zahlen*.

[Alfons Mittelmeyer]

Ich sprach nicht von kleineren Zeilen, sondern von kleinen *Zahlen*.

Sorry hab mich verlesen. Aber Dir ist klar, dass es in dem Beispiel mit der Zahl nicht um Zahlen ging. Sondern eine Zahl zu nehmen, nur ein Beispiel war, oder etwa nicht?

[snafu]

Ja, ist mir bewusst. Es sollte nur ein weiteres praxisfernes Beispiel sein, um deine Theorie zu untermauern.

Den Effekt von `del` möchte ich übrigens auch nicht in Abrede stellen. Ich sage aber (wie auch viele andere), dass man sich keinesfalls auf den Effekt von `del` im Hinblick auf eine Speicherfreigabe verlassen kann und `del` eigentlich auch nicht für diese Art von Anwendung gedacht ist. Daher wird `del` in der Praxis auch kaum verwendet. Und wenn man es einsetzt, dann in aller Regel auch nur wegen des Effekts auf den Namensraum, jedoch nicht, um Speicher freizugeben.

Interessanter wäre es, zu zeigen, welchen Anteil ein Entfernen nicht mehr benötigter Programmteile durch `del` man in Bezug auf den gesamten Speicherverbrauch eines Programms hätte. Aber dies bitte nicht durch ein isoliertes, völlig theoretisches Beispiel, sondern anhand eines realen, für den Endanwender lauffähigen (GUI-)Programms.

Übrigens: Wenn man wirklich an solchen Optimierungen optimiert ist, dann möchte man sich möglicherweise mal alternative Python-Implementierungen ansehen, insbesondere: PyPy. Ich weiß nicht, ob PyPy tatsächlich erkennen kann, ob bestimmte Programmteile garantiert nie wieder verwendet werden und somit gelöscht werden können, aber einen Blick wäre es jedenfalls wert. Nur mal so als Alternative zu eigenen Lösungen...

[jens]

Eine Programmierer sollte Programme schreiben und nicht tagelang darüber nachdenken, ob er jetzt del nehmen soll oder es vielleicht doch nicht braucht

Ähm. Wir sagen dir doch die ganze Zeit, das du dir erstmal keine Gedanken zum Thema Speicherverschwendung machen sollst. Du nimmst dir es aber nicht an.

... da sein Computer ja 8GB Speicher hat und er ihn abends wieder ausschaltet und daher ruhig in den Speicher müllen kann. Ohne die Randbedingungen und die Endanwendungen zu kennen, kann so eine Frage nicht entschieden werden. Wenn eine Endanwendung auf einem Gerät mit 40 MB laufen würde und das Gerät monatelang nicht ausgeschaltet würde, hätte man laufend einen Crash. Der Grundsatz guter Programmierung heißt einfach, dynamisch allokierten Speicher, den man nur vorübergehend braucht, immer nach Gebrauch wieder freigeben und nicht das nächste mal wieder neu allokieren, bis kein Speicher mehr übrig ist. Du möchtest schließlich auch nicht mit einem Flugzeug abstürzen oder einen Autounfall haben, weil jemand den Speicher vollgemüllt hat.

Natürlich will niemand Programm mit Memory-Leaks... Aber du nutzt Python mit einem GC und kein Assembler oder C oder eine andere Sprache, bei der du das Speichermanagement selbst machen mußt... Natürlich kann man in Python auch eine Art "Memory-Leaks" Effekt bauen. Hast du ja mit deinen "Test-Skripten" gezeigt. Aber das ist erstmal Praxisfern...

Nochmal:

Du merkst irgendwie nicht, das du in der Premature optimization is the root of all evil Endlosschleife bist, oder?!?

Wie oft willst du noch hören, das es realitätsfern ist?

Mach erstmal. Wenn du wirklich Speicherprobleme bekommst, kannst du drüber nachdenken...

Du denkt aber in einer Endlosschleife über fiktive Probleme nach...

Müssen wir bald übergehen zu:

Code: Alles auswählen

while True:
    print("Do Not Feed The Troll")

[BlackJack]

@Alfons Mittelmeyer: Grundwissen musst Du Deiner Meinung nach nicht als gegeben hinnehmen‽ Das würde vielleicht einiges erklären.

Ich weiss jetzt auch nicht wo ich Unsinn behauptet habe. Du hast *immer noch nicht* belegt das a) überhaupt ein Problem besteht das gelöst werden muss, und b) das ``del`` auf Funktionen die normal in den unendlich vielen Modulen die geladen werden sollen, überhaupt einen Effekt hat. Und dann bleibt da auch immer noch das es den Python-Entwicklern freigestellt ist Speicher für Funktionen aus Modulen erst freizugeben wenn der gesamte Code aus dem Modul nicht mehr benötigt wird. Was wie ich schon ausgeführt habe *sinnvoll* sein kann, insbesondere auch was den Speicherverbrauch angeht!

Der Programmcode von Modulen bleibt sehr wohl im Speicher denn der besteht ja aus dem Code aller im Modul (potentiell) definierten Funktionen und Methoden. Wenn der Code der definierten ”callables” nicht im Speicher bliebe, könnte man diese ja nicht ausführen.

*Man* will nicht Funktionen durch ``del`` als Garbage markieren, *alleine* *Du* willst das, und das versteht keiner, weil a) ``del`` so nicht funktioniert und b) es keinen Sinn macht auf gut Glück diese Verbindung zwischen Namen und Funktion zu trennen und darauf zu hoffen dass der Speicher für den Funktionscode dann freigegeben wird. Das ist nicht garantiert und diese zusätzliche äusserst ungewöhnliche Aktion auch nicht wert. Wir erinnern uns an dieser Stelle nochmal daran das Du noch immer nicht gezeigt hast das es ein reales Problem gibt was damit gelöst werden könnte.

Wo wurde die Behauptung aufgestellt das der Funktionscode automatisch von der Speicherbereinigung gelöscht wird? Das hat AFAIK niemand geschrieben.

Du solltest wirklich noch mal drüber nachdenken ob Python für Deine Ansprüche an den Speicherverbrauch und die Verwaltung von selbigen wirklich die richtige Sprache ist, oder ob Du nicht lieber eine verwenden möchtest, bei der man tatsächlich garantierten Einfluss auf die Speichverwaltung hat. Denn bei Sprachen mit automatischer Speicherverwaltung hast Du es nicht in der Hand Speicher so früh wie möglich freizugeben *und* automatische Speicherverwaltungen sind in der Tat aus guten Gründen teilweise so gestrickt das sie genau das tun was Du nicht möchtest: den freien Speicher so lange ”zumüllen” bis ein gewisser Füllgrad erreicht ist, und sich erst *dann* verstärkt um die Bereinigung zu kümmern. Oder nebenher in einem eigenen Thread, wobei dann oft auch mehr Speicher belegt ist als zu einem gegebenen Zeitpunkt tatsächlich belegt sein müsste. Dabei besteht dann auch die Gefahr, dass dauerhaft mehr Speicher angefordert als bereinigt wird und das Programm dann irgendwann angehalten wird bis der Speicherverwaltungs-Thread mindestens bis zu einer definierten Untergrenze an vorhandenem ”Müll” alles abgeräumt hat. Die Frage ob Du ``del`` verwendest oder nicht ist also keine Frage der Randbedingungen Deiner Anwendung und/oder Hardware, sondern ob die automatische Speicherverwaltung diesen Bedingungen genügt. Und das tut sie laut Python-Sprachspezifikation und auch realen Python-Implementierungen *nicht* also ist das ``del`` Unsinn, und bei bestimmten Randbedingungen Python allgemein die falsche Sprache. ``del`` ist schlicht nicht als Mittel zur manuellen Speicherverwaltung konzipiert. Es dafür verwenden zu wollen ist *falsch*.

In Flugzeugen und Autos kommt Python, oder Java, oder…, an solchen Stellen wo der Speicherverbrauch wirklich hart begrenzt werden muss weil es sonst eine Katastrophe geben kann, ganz sicher nicht zum Einsatz. Da braucht man sich also keine Sorgen machen.

[Alfons Mittelmeyer]

Eine Programmierer sollte Programme schreiben und nicht tagelang darüber nachdenken, ob er jetzt del nehmen soll oder es vielleicht doch nicht braucht

Ähm. Wir sagen dir doch die ganze Zeit, das du dir erstmal keine Gedanken zum Thema Speicherverschwendung machen sollst. Du nimmst dir es aber nicht an.

Falsch, ich mache mir keine Gedanken zur Speicherverwaltung und benutze einfach del. Wer sich Gedanken macht, dass man es nicht benutzen soll, seid Ihr.
Wie gesagt, nicht lange nachdenken, einfach del nehmen, anstatt Expertisen erstellen zu lassen, in wieviel Tagen es durchschnittlich bei diesen und jenen Geräten zum Crash kommt, wenn man del nicht nimmt, und mit welchen Risken diese Crashs bei diesen und jenen Einsatzzwecken verbunden wären.

Ihr erwartet jetzt wohl, dass ich das jetzt untersuche? Nö gewiss nicht, da ist mir meine Zeit viel zu schade. Da implementiere ich lieber und nehme del.

[Hyperion]

Ihr erwartet jetzt wohl, dass ich das jetzt untersuche? Nö gewiss nicht, da ist mir meine Zeit viel zu schade. Da implementiere ich lieber und nehme del.

Du hast jetzt schon verstanden, dass ``del`` keinerlei Garantie über die Freigabe von Speicher macht? (oder wie BlackJack es ausdrückte, dass "``del`` schlicht nicht als Mittel zur manuellen Speicherverwaltung konzipiert ist".)

Wie stehst Du zu dieser Aussage? Hältst Du sie für falsch? Behauptest Du das Gegenteil?

Nimm doch mal wirklich konkret Bezug zu dieser einen Aussage von BlackJack!

[BlackJack]

@Alfons Mittelmeyer: Wenn Du nicht über die korrekte Verwendung von ``del`` nachdenken willst, dann sag das doch gleich das Dir egal ist das Du es falsch verwendest, statt den Unsinn über 12 Seiten lang irgendwie doch rechtfertigen zu wollen.

[snafu]

Ihr erwartet jetzt wohl, dass ich das jetzt untersuche? Nö gewiss nicht, da ist mir meine Zeit viel zu schade. Da implementiere ich lieber und nehme del.

Nee, genau dies habe ich *nicht* ernsthaft von dir erwartet. Spätestens hiermit hast du dich hoffentlich für jeden Mitlesenden, der kurzzeitig geglaubt hatte, dass deine `del`-Ausführungen einen praxisrelevanten Nutzen hätten, selbst disqualifiziert.

[Alfons Mittelmeyer]

Ihr erwartet jetzt wohl, dass ich das jetzt untersuche? Nö gewiss nicht, da ist mir meine Zeit viel zu schade. Da implementiere ich lieber und nehme del.

Du hast jetzt schon verstanden, dass ``del`` keinerlei Garantie über die Freigabe von Speicher macht? (oder wie BlackJack es ausdrückte, dass "``del`` schlicht nicht als Mittel zur manuellen Speicherverwaltung konzipiert ist".)

Wie stehst Du zu dieser Aussage? Hältst Du sie für falsch? Behauptest Du das Gegenteil?

Nimm doch mal wirklich konkret Bezug zu dieser einen Aussage von BlackJack!

Die Aussage ist richtig und ich behaupte auch nicht das Gegenteil. Aber bei einer globalen Funktion nicht del zu benutzen oder den Namen umzudefinieren ist die Garantie dafür dass diese Funktion auch nach Beseitigung aller anderen Referenzen nicht Garbage werden kann.

Dagegen ist del zu benutzen eine Garantie dafür, dass eine Funktion zu Garbage wird, wenn:
diese Funktion nirgends sonst referenziert wird. Das heißt, wenn keine andere Funktion diese Funktion aufruft und keine Variable oder sonstiges Objekt auf diese Funktion verweist

Und das ist hier der Fall, und genau für diesen Fall will ich del benützen:

Code: Alles auswählen

step1()
step2()

def myfunction():
  step3()
  step4()

myfunction()
del myfunction

step5()
step6()

Oder ich benütze keine solche Funktion und dann heißen die Callback Funktionen alle function und globale Variablen muß ich dann mit VAR['name'] vermeiden.

[snafu]

Der Test war diese Funktion variabel hochgezählt:

Code: Alles auswählen

def function1000000():
	print "function1000000: This isn't much, normally it should be a GUI"

Dieser Test zeigt, dass ein Definieren von hunderttausenden Funktionen den Speicher irgendwann in die Knie zwingen kann, da Python erstmal gezwungen ist, all diese Funktionen wegen der möglicherweise noch folgenden Verwendung im Speicher vorzuhalten. Durch `del` zeigt man Python in der Tat, dass man nicht weiter an einer Verwendung der Funktionen interessiert ist. Oder zumindest löscht man eine Referenz auf die Funktion und somit besteht zumindest in diesem isolierten Fall höchstwahrscheinlich keine weitere Referenz mehr, sodass das Objekt als nicht mehr erreichbar und damit löschbar angesehen werden kann. Damit zeigst du aber nichts, was nicht schon zuvor bekannt war.

Was man dir zu sagen versucht, ist vielmehr: Der Effekt von `del` auf den Speicher ist grundsätzlich zufällig und abhängig von der Python-Implementierung. Der Effekt eines Löschen nicht mehr benötigter Programmteile ist in normalen Programmen speichermäßig völlig zu vernachlässigen. Die von dir angegebenen `del`-Zeilen sollten also allein schon wegen der Lesbarkeit und aufgrund möglicher Missverständisse aus dem Programm entfernt werden. In deinen Programmen werden sie wahrscheinlich auf ewig verbleiben, weil du dich von deiner Überzeugung ohnehin nicht abbringen lässt, aber ich möchte hiermit zumindest andere Leser vor einer solchen Verwendung warnen.