Das deutsche Python-Forum

BlackJack hat geschrieben:In *der* Python-Dokumentation steht bei `partial()` eine in Python geschriebene Beispielimplementierung wie `partial()` grob funktioniert. Wenn Du das nicht zu gebrauchen findest, dann liegt das vielleicht nicht an Dir sondern an noch fehlendem Verständnis wie Python funktioniert.

Probiere doch einmal aus:
Das echte partial zeigt local_name, die Beispiele zeigen global_name, sind also unbrauchbar.

Und was soll das, anderen mangelndes Verständnis unterstellen zu wollen, wenn es anscheinend am eigenen Verständnis der Sache fehlt

@Alfons Mittelmeyer: Das Beispiel ist nicht unbrauchbar, es zeigt wie man `partial()` selber implementieren kann. `example_partial()` verhält sich hier anders als als `functools.partial()`, aber bei `locals()` wäre ich sowieso keine Wette eingegangen was das als Ergebnis bringt, denn man weiss ja gar nicht wie das innen drin aussieht. Man könnte das ja noch ganz anders implementieren. Oder anders gesagt: Mir war auch schon vor dem ausführen von Deinem Beispiel klar das `locals()` nicht sinnvoll mit einer `partial()`-Implementierung nutzbar ist, weil das die lokalen Namen beim *Aufruf* liefert und nicht wie Du anscheinend gerne hättest, die lokalen Namen an der Stelle wo man die Funktion als Argument übergeben hat. So funktioniert Python nun mal nicht.

Ich bekomme übrigens *nicht* `globale_name` — bei keiner der beiden Varianten. Wäre wie gesagt auch das letzte was ich erwarten würde.

Bei `functools.partial()` liefert `locals()` die lokalen Namen von einer Aufrufebene höher weil es in C geschrieben ist, also selbst gar keine lokalen Namen hat, aus Python-Sicht. Daher der Unterschied zum `example_partial()`.

Ich verstehe was Da passiert. Und Du (noch) nicht. Das ist keine Unterstellung, sonst würdest Du ja nicht die Fragen stellen die Du gerade stellst.

Statt 25 Zeilen verquirltes Python zu schreiben hättest Du auch zweimal locals() in unterschiedlichen Kontexten aufrufen können, um das gleiche Resultat zu erzielen, das übrigens mit der Bescheibung der Dokumentation übereinstimmt.

BlackJack hat geschrieben:Ich verstehe was Da passiert. Und Du (noch) nicht. Das ist keine Unterstellung, sonst würdest Du ja nicht die Fragen stellen die Du gerade stellst.

Lass bitte Deine Unterstellung. Ich verstehe genau, was passiert. Das mit global_name war ein Versehen, weil ich zuerst anderes probiert hatte. Und dann nicht mehr genau geschaut hatte. Es sind natürlich die locals innerhalb newfunc.

Eine normale Python Funktion scheidet also schon einmal aus.

Was ich brauche sind die locals eine Stufe höher und wäre auf C-Ebene lösbar, das ist mir alles klar. Anscheinend kennst Du auch keine sonstige Python Funktion, mit der man auf python Ebene an die locals herankommt wie bei partial und welche die gewünsche Syntax erlaubt. Wenn ich Fragen stelle, dann in der Hoffnung, daß so ein Fachmann wie Du, vielleicht doch einen Python Kniff kennt, mit dem es zu machen wäre. Aber anscheinend ist das nicht der Fall.

Und vielleicht hast Du ja mittlerweile auch verstanden, daß es gerade darum geht, an die richtigen locals heranzukommen. Deinen Antworten habe ich entnommen, daß Du das bisher nicht kapiert hattest.

Hallo,

ich oute mich dann auch mal: nein, ich habe es nicht verstanden, das Ziel. Was mir auch völlig unklar ist, warum der Proxy auch TCP laufen soll, wenn es um die Manipulation der Frames eines GUI Designers geht. Zumal man ja auch bei Tkinter auf alle Elemente des Root-Windows zugreifen kann und die GUI ja immer lokal läuft.

Außerdem sind wir hier im Thread ja von einem KeyError über einen wie auch immer geachteten Proxy jetzt bei locals() sind. Mal sehen, wo es am Ende wirklich endet...

Also: ich bin raus. Aber ich mache mir in weiser Voraussicht schon mal etwas Popcorn *SCNR*

Gruß, noisefloor

Alfons Mittelmeyer hat geschrieben: Was ich brauche sind die locals eine Stufe höher und wäre auf C-Ebene lösbar, das ist mir alles klar.

Du kennst noch nicht mal die Semantik von Python, aber die Interna des Interpreters sind dir so sonnenklar, dass du das da loesen kannst? Iss klar

Vielleicht kommt dir ja irgendwann mal der Gedanke, dass gegen die Sprache anzuprogrammieren keine so gute Idee ist. Sondern es besser waere, idiomatisch Python zu schreiben. Aber ich setze darauf sicher kein Geld

__deets__ hat geschrieben: Du kennst noch nicht mal die Semantik von Python, aber die Interna des Interpreters sind dir so sonnenklar, dass du das da loesen kannst? Iss klar

Mit beträchlichem Zeitaufwand könnte ich selbstverständlich eine Erweiterungsbibliothek in C schreiben, die das Problem lösen würde. Und dabei muß auch nicht alles sonnenklar sein, da bräuchte ich mir nur die Implementierung von functools und die von partial in C-Python anzusehen.

Aber das habe ich keineswegs vor. Ich habe auch nicht vor, gegen die Sprache anzuprogrammieren, deshalb hatte ich die Frage gestellt, ob jemand von Euch etwas kennt, womit es mit Python Mitteln lösbar wäre.

Wenn einige hier überfragt sind, ist das lange kein Grund sich aufzumandeln und jemanden der eine Frage gestellt hat, anscheinend niedermachen zu wollen.

So ziemlich ALLES was du hier so an Code geliefert hast ist gegen die Sprache programmiert. Und nein, dieses Prädikat gilt auch dann, wenn man es irgendwie im bestehenden Interpreter hinkriegt, das es "funktioniert".

Code, der an seinem Ausführungsort annahmen darüber trifft, WO er ausgeführt wird, ist IMMER schlechter Code. Das gilt schon wenn man sich zB durch Datenstrukturen hangelt (siehe Demeter Law ), oder aus einem Widget hochwandest in seine Eltern ( wie von dir an anderer stelle propagiert), und erst recht, wenn man sich die stackframes betrachten möchte. Was übrigens durchaus geht (und es wissen die vermeintlichen Nixkönner hier auch allesamt wie. Frohes suchen).

Also wird hier nicht gemandelt - sondern einfach nur wiederholt festgestellt, das du leider vollkommen beratungsresistent bist.

@Alfons Mittelmeyer: Das ich das Ziel nicht verstanden habe, hatte ich ja bereits explizit geschrieben, schön das Du das meinen Antworten entnommen hast.

Das `functools.partial()` die `locals()` von einer Aufrufebene höher genommen werden ist ein Nebeneffekt der Implementierung. Das wird ja nicht explizit gemacht, sondern ergibt sich halt, rein dadurch das die Funktion in C implementiert ist. Im Grunde ist das ja auch gar nicht eine Aufrufebene höher, sondern die letzte Aufrufebene in der eine in Python implementierte Funktion aufgerufen wurde.

Wie man an die lokalen Namen des Aufrufers kommen könnte, wüsste ich schon, allerings ist das zu viel Magie für ein normales Programm und muss so auch nicht in jeder Python-Implementierung funktionieren. Und natürlich gibt es Probleme wenn man anfängt beteiligte Funktionen, also zum Beipiel den Aufrufer, in C zu implementieren, weil es dann vom Aufrufer gar keine lokalen Namen gäbe und man die vom Aufrufer davor bekäme. So etwas wäre alles andere als robust.

@BlackJack: Danke für Deine Antwort. Ich hatte die Idee, ob ich mit wenig Aufwand aus meinem GuiDesigner Funktionsaufrufe auf Funktionen, die von globalen Variablen Gebrauch machen, herausbekomme und duch etwas anderes ersetzen kasnn, das genauso aussieht, aber keine globale Variable benützt. Der Aufwand wäre beträchtlich, bei send und do receive wären es wohl etwa 200 Zeilen und wenn man alles so haben möchten, währen es wohl ein paar Tausend Zeilen. Die Syntax wäre auch nicht erwünscht.

Also noch mal genau, es handelt sich hier nicht um eine Biblothek, die für sonstige allgemeine Aufgaben vorgesehen. Das Kommuniksationsmodul hat keine globalen Variablen, sondern nur das DynTkInter Modul, welches nur für eine einzige Instanz von tkinter.Tk vorgesehen ist und benutzt wird innerhalb von GuiApplication().mainloop()

Bisher wird der Proxy bei GuiApplication() also bei tkinter.Tk() für die Gui Application angelegt und für diese als globale Referenz gespeichert. Bei anderen Modulen, die nicht die Gui aufbauen, wird das nicht importiert.

Es ist auch nicht der Sinn self.communication.send zu schreiben, denn die Gui Schripte sollen nicht interna der Implementierung widerspiegeln, sondern die Mittel des Befehlssatzes gebrauchen. Es wähe auch nicht der Sinn, in Python so etwas schreiben zu müssen, wie statt if schreibe man:

self.python.statements.simple_statements.if

So etwas ginge sicher gegen die Sprache und gegen die Sprache von DynTkInter GUI Skripten geht self.communication.send

Wer den Proxy benutzen will, kann sich ja einen eigenen erzeugen und es so tun. Normalerweise benutzt sowieso keiner DynTkInter, aber mein GuiDesigner braucht die erweiterte Funktionalität der Widget Klassen. Ich sollte wohl besser noch das Exportieren von Menüs im tkinter Stil fertigstellen, die Behandlung von Photoimages im tkinter Stil und Gridtabellen mit rowconfigure und columnconfigure im tkInterstil. Dann wrd eine DynTkExtend Bibliothek hinfällig und eine abgeleitete Menüklasse braucht man dann nur, wenn man in Menüs für command Buttons, cascaden usw. Namen mit angeben will, damit die dann vor dem tkinter Aufruf wieder entfernt werden.