Gui-Anderung einer Eigenschaft in einem anderen Modul

[BlackJack]

@Alfons Mittelmeyer: Welche Kanonen und welche Spatzen? Ich schrob schon mal das es für das Publisher/Subscriber-Modell fertige Lösungen für alle möglichen ”Preisklassen” gibt und habe im letzten Beitrag ja auch das `pubsub`-Modul von wxPython erwähnt. Das kommt also auch aus der GUI-Ecke. Es gibt auch auch noch andere Module.

Wenn man mehrere offene Python-Anwendungen miteinander kommunizieren lassen möchte, dann sollte man allerdings tatsächlich mal in Richtung Message-Queues schauen, denn genau für solche Kommunikation sind die ja gedacht. Unter Linux könnte man sich auch DBus anschauen. Die beiden ”grossen” GUI-Rahmenwerke bieten dafür Unterstützung beziehungsweise Qt direkt und bei Gtk baut man ja normalerweise auf den glib-*-Bibliotheken auf und die glib-GIO-Bibliothek bietet DBus-Funktionalität.

[jerch]

@Alfons Mittelmeyer:
Das mit den Bauds ist praktisch - könnte man auch gleich als Heartbeat verwenden. KA, wofür Du das brauchen könntest. Wie kommst Du darauf?

[Alfons Mittelmeyer]

Irgendwo scheint Ihr wohl nichts zu kapieren.

Das ist nur allzu menschlich. Jeder von uns hat blinde Flecke mit nahezu null Ahnung. Das ist nicht schlimm. Viel gefährlicher ist Halbwissen. Es verleitet uns immer wieder, Dinge zu behaupten und zu tun, wo sich der gesunde Menschverstand an den Kopf fassen möchte.

Jerch, das Schlimme ist nicht Halbwissen. Das Schlimme ist, wenn man glaubt, Expertenwissen zu haben. Experten wissen, was in der Dokumentation steht, was in Büchern steht, was andere dazu geschrieben haben und welche Erfahrungen sie dabei gemacht haben. Und daraus haben sich dann solche Experten ihre Meinungen gebildet. Haben die oft gesagt und geschrieben. Und besonders schlimm ist, wenn man nicht nur etwas glaubt, sondern ganz fest glaubt es zu wissen. Echtes Wissen wird nicht aus Büchern und Meinungen erworben, sondern durch Erkenntnis. Und dann passiert leider immer wieder, Du zeigst, dass etwas anders ist, als ein sogenannter Experte behauptet hat. Und er will es einfach nicht wahr haben. Will es nicht kapieren und beharrt weiter auf seiner Überzeugung und rückt davon keinen Schritt breit ab.

Wichtig ist, offen für Neues zu sein, und alles zu überdenken und überprüfen, anstatt mit vorgefertigten Meinungen, Denkschablonen und Vorurteilen daher zu kommen.

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: Wenn ich beliebig viele Tasks miteinander kommunizieren lassen möchte dann nehme ich trotzdem nichts was von einem Anfänger zusammengebastelt wurde, sondern etwas das sich schon in der Praxis bewährt hat. Also zum Beispiel das `pubsub`-Modul von wxPython oder ØMQ oder RabbitMQ wenn das ganze auch richtig fett skalieren können soll.

Erstens einmal, was heißt denn Anfänger? Ein Python Neuling hat zwar noch nicht lange mit Python programmiert. Das heißt aber nicht, dass er ein Anfänger als Programmier wäre, Vielleicht hatte ein Python Anfänger bereits mehr Programmiererfahrung als Du, als Du noch gar nicht geboren warst. Also brauchst Du nicht abwertend solche Begriffe, wie Anfänger zu gebrauchen. Außerdem wurmt es Dich wahrscheinlich, dass ich jetzt ein ganzes Messaging System über mehrere Tasks gemacht habe, obwohl Du bis zuletzt steif und fest behauptet hattest, dass die tkinter Events zu fast nichts zu gebrauchen wären, weil man da keinen Parameter angeben kann.

Und was willst Du mit fett skalieren? Wenn Du das wsillst, dann musst Du ein Echtzeitbetriebsssystem wie QNX nehmen. Da kannst Du Taskprioritäten angeben, den dafür vorgesehenen Speicherverbrauch und auch wieviel Zeit dieser Task prozentual zu anderen verbrauchen darf. Python gibt es auch für QNX. Aber Python soll man da nur für Lernzwecke, Prototyping und Testen verwenden. Denn die Kriterien für Sicherheit, Schnelligkeit und Skalierbarkeit und Zuverlässigkeit erfüllt es nicht. Also für echte Skalierbarkeit, kein Windows, kein Linux und kein Python.

Und außerdem, was willst Du da groß skalieren? Hier wird eine Message gesendet. Könnte innerhalb der eigenen Task sein, oder an eine andere:

Code: Alles auswählen

def send(self,msgid,msgdata=None):
    self.Queue.put((msgid,msgdata))
    self.trigger()

Die Message wird einfach in die Queue gelegt und ein Trigger gesetzt zur Verabeitung. Also, wie willst Du das skalieren?

Und was ist der Trigger? Genau jener, von dem Du bis zuletzt steif und fest behauptet hast, dass er fast zu nichts zu gebrauchen wäre, weil man ihm keinen Parameter übergeben kann:

Code: Alles auswählen

proxy.set_trigger(lambda: root.event_generate("<<SEND>>", when="tail"))

Ich finde diesen Event super, kann man nämlich alles Denkare damit anstellen.

Also, dann erkläre einmal, wie Du das skalieren willst:

Code: Alles auswählen

def send(self,msgid,msgdata=None):
    self.Queue.put((msgid,msgdata))
    root.event_generate("<<SEND>>", when="tail")

Und am Besten erklärst Du dann auch noch, warum Deiner Meinung nach event_generate zu fast nichts zu gebrauchen ist.

[jerch]

Echtes Wissen wird nicht aus Büchern und Meinungen erworben, sondern durch Erkenntnis.

Schule ohne Bücher und Lehrer. Das die Menschheit da nicht früher drauf gekommen ist.

Und was willst Du mit fett skalieren? Wenn Du das wsillst, dann musst Du ein Echtzeitbetriebsssystem wie QNX nehmen. Da kannst Du Taskprioritäten angeben, den dafür vorgesehenen Speicherverbrauch und auch wieviel Zeit dieser Task prozentual zu anderen verbrauchen darf. Python gibt es auch für QNX. Aber Python soll man da nur für Lernzwecke, Prototyping und Testen verwenden. Denn die Kriterien für Sicherheit, Schnelligkeit und Skalierbarkeit und Zuverlässigkeit erfüllt es nicht. Also für echte Skalierbarkeit, kein Windows, kein Linux und kein Python.

Damit auch Du weisst, was gemeint ist (Achtung, moderne Form des Buches und daher evtl. völlig ungeeignet): https://de.wikipedia.org/wiki/Skalierbarkeit

[BlackJack]

@Alfons Mittelmeyer: Anfänger heisst das Du noch nicht lange mit Python arbeitest und sowohl sehr unpythonischen Code als auch falsche Vorstellungen wie die Sprache funktioniert demonstriert hast. Und wenn es dann Lösungen gibt die schon lange bestehen, schon zum Praxiseinsatz gekommen sind, und von Programmierern von grösseren Python-Projekten stammen, dann würde ich die halt vorziehen. Das ist einfach gesunder Menschenverstand. Das Du das abwertend aufgefasst hast, lässt vielleicht doch, zumindest unterbewusst, auf ein bisschen Erkenntnis deinerseits hoffen. Denn die ist ja wichtig, wie Du selbst sagst. Das wurmt Dich anscheinend ein bisschen das mit dem Anfänger…

Ich bin auch weiterhin der Meinung das die virtuellen Ereignisse nicht wirklich zu gebrauchen sind und Du bestätigst mich darin: Man muss nämlich erst einen Haufen Code drumherum basteln um etwas zu bekommen das bei anderen GUI-Rahmenwerken schon von Haus aus angeboten wird. Das behaupte ich nicht einfach steif und fest sondern sehe mich in der praktischen Verwendung der virtuellen Ereignisse bestätigt: Man findet die in der Praxis selten und sehr viel häufiger das „pollen“ einer Queue mittels `after()`-Methode.

Skalieren will ich gar nichts, man könnte aber. Wenn Du wissen willst wie, dann schau doch einfach mal bei den verschiedenen Message-Queues was die so können. Halt ein bisschen mehr und verteilter als Deine Implementierung. Aber nochmal: Man muss die ja nicht nehmen wenn man das nicht benötigt.

Was die auch gemeinsam haben: Es gibt sie in „pythonischem“ Code und über die üblichen Wege installierbar. Deins ist Code in einem Forum den man sich erst zusammensuchen müsste und selber irgendwie installieren müsste. Ohne Homepage, ohne Bugtracker, ohne Versionsgeschichte, …

[Alfons Mittelmeyer]

Ich bin auch weiterhin der Meinung das die virtuellen Ereignisse nicht wirklich zu gebrauchen sind und Du bestätigst mich darin: Man muss nämlich erst einen Haufen Code drumherum basteln um etwas zu bekommen das bei anderen GUI-Rahmenwerken schon von Haus aus angeboten wird.

Etwa hundert Zeilen ist ja keine Menge Code. Für manche ja schon, für mich eher ein Klacks. Und basteln ist der falsche Ausdruck. Das ist Code vom Feinsten. Und von Hause aus gibt es gar nichts. Irgendwann hat jemand den Code dafür geschrieben. Und jetzt habe ich ihn eben für tkinter Events mit einer Queue geschrieben.

Das behaupte ich nicht einfach steif und fest sondern sehe mich in der praktischen Verwendung der virtuellen Ereignisse bestätigt: Man findet die in der Praxis selten und sehr viel häufiger das „pollen“ einer Queue mittels `after()`-Methode.

Als Experte weisst Du ja, was in der Praxis gemacht wird. Das heißt aber nicht, dass man sich daran halten sollte, wie es andere in der Praxis machen. Was Du mir jetzt erzählt hast, das ist eine Stümperei, die da in der Praxis gemacht wird, also so schlimm hatte ich es mir nicht gedacht. Bei after kann man einen Parameter übergeben, da braucht man dann gar keine Queue, bei dem Event schon, dafür wird es ja ohne Zeitverzug auch gleich getriggert. Also eine Queue bei after ist völlig unnötig und dann noch pollen, das schlägt doch dem Faß den Boden aus. Also solche Dinge solltest Du wirklich niemand empfehlen, auch wenn andere in der Praxis so einen Schrott machen. After ist schon schlecht und dann mit Queue noch schlechter - weil unnötig - und noch pollen, ganz schlecht.

Was die auch gemeinsam haben: Es gibt sie in „pythonischem“ Code und über die üblichen Wege installierbar. Deins ist Code in einem Forum den man sich erst zusammensuchen müsste und selber irgendwie installieren müsste. Ohne Homepage, ohne Bugtracker, ohne Versionsgeschichte, …

Sorry dass ich als Python Neuling auch noch nichts veröffentlicht hatte. Hatte ja erst gestern den Gedanken mit dem packed Flag gehabt und dass man dann auch über mehrere Tasks Messages austauschen kann. Ist also noch ganz frisch diese Version und fehlt auch noch die Destroy Methode. Die hatte ich bisher nicht gebraucht, da ich das bisher nur für eine Task genommen hatte. Und eine Kleinigkeit überlege ich mir noch, ob lieber mit einem trigger nur eine Message oder gleich die restlichen auch. Wenn nämlich zwischen root=tk.Tk() und mainloop bereits externe Messages eintreffen, könnte das für manche ein Problem verursachen. Bisher hatte ich mit dem Event noch kein Problem festgestellt, hatte es allerdings auch noch fast nicht benutzt, da man bei nur einer Task auch bei der Methode bleiben kann, die ich zwischen tk.Tk() und mainloop benütze.

Aber immerhin hat man hier doch einen relativ einfachen und leicht nachvollziehbaren Python Code mit wenigen Zeilen - kaum über hundert - in nur einem Modul, oder etwa nicht? Für Programmieranfänger aber wohl schon einige Denkarbeit nötig. Aber denken schadet nicht, oder?

[Alfons Mittelmeyer]

Um vielleicht mal zu verstehen, worum es dabei geht. Wenn man an senden denkt, denkt man an Messages, denkt man daran, dass die irgendwie sich durch ein System bewegen. Aber das ist nur ein Gedanke, wie man es sich vorstellen könnte. In Wirklichkeit geht es um Funktionaufrufe. Wenn man einen Event hat, wie <Return>, dann sendet der nichts, sondern ruft die daran gebundene Funktion auf. Und dasselbe findet statt, bei dem, was ich Messages genannt hatte. Es sind direkt aufrufbare Events. Und die Funktion zum Aufrufen von solchen Events, hatte ich 'send' genannt, aber wie gesagt, ist das nur eine Vorstellung.

Gehen wir mal aus davon, was in frage.py geschieht:

Code: Alles auswählen

frage = input("> ")
extern_proxy.proxy.send("FRAGE",frage)

Also, man übergibt einfach diese Daten an den extern_proxy und sagt ihm, er soll das ausführen. Und weil auch andere Tasks an den etwas übergeben könnten, nimmt man zur Sicherheit eine Queue:

Code: Alles auswählen

def send(self,msgid,msgdata=None):
    self.Queue.put((msgid,msgdata))
    self.trigger()

Also die Daten werden zur Ausführung beim extern_proxy auf die Queue gelegt und man triggert die Ausführung. Die Funktion zur Ausführung darf man nicht direkt aufrufen, weil das ja eine andere Task ist. Diese Task muss diese Funktion selber aufrufen. Man muss ihr dafür lediglich melden, dass die Daten jetzt da sind. Das macht die Funktion self.trigger(). Im Falle vom extern_proxy wird da ein Event gesetzt:

Code: Alles auswählen

self.event.set()

Das sorgt für den Taskwechsel und der extern_proxy führt dann die zugehörige Funktion aus. Welche das ist, hatte das Modul antwort.py ihm bekanntgegeben durch:

Code: Alles auswählen

proxy.do_receive_extern(("FRAGE",))

Dabei handelt es sich um folgende Funktion im proxy für antwort.py:

Code: Alles auswählen

def receive_extern(self,message):
    self.Queue.put(message)
    self.trigger()

Der extern_proxy ruft also diese Funktion auf und übergibt dadurch die Daten an den Proxy von antwort.py In diesem Falle handelt es sich bei self.trigger() um jenes tkinter event:

Code: Alles auswählen

root.event_generate("<<SEND>>", when="tail")

Dadurch übernimmt der Proxy von antwort.py die Bearbeitung und ruft dann die zugehörige Funktion auf und die wurde ihm bekannt gegeben durch:

Code: Alles auswählen

proxy.do_receive(root,"FRAGE",get_frage)

Das ist dann diese Funktion:

Code: Alles auswählen

def get_frage(msg):
    frage['text'] = msg
    antwort.delete(0,'end')

Um es zusammenzufassen. Nach dem send werden dann folgende zwei registrierte Callback Funktionen ausgeführt:

Code: Alles auswählen

def receive_extern(self,message):
    self.Queue.put(message)
    self.trigger()

def get_frage(msg):
    frage['text'] = msg
    antwort.delete(0,'end')

Es handelt sich also um zwei unterschiedlich definierte Callbackfunktionen für zwei verschiedene Proxis für diesselbe Message Id "FRAGE"

Und verwendet wurden dabei folgende zwei unterschiedliche Trigger, die aber im Prinzip das Gleiche machen:

Code: Alles auswählen

self.event.set() # für threading event loop
root.event_generate("<<SEND>>", when="tail") # für tkinter mainloop

[snafu]

Wer weiß. Vielleicht ist unser Alfons am Ende ein verkanntes Genie, der die Programmierung komplett neu erfindet und alles bisher da gewesene in den Schatten stellt...

[jens]

Echtes Wissen wird nicht aus Büchern und Meinungen erworben, sondern durch Erkenntnis.

Schule ohne Bücher und Lehrer. Das die Menschheit da nicht früher drauf gekommen ist.

lol

[BlackJack]

@Alfons Mittelmeyer: Hundert Zeilen Code für etwas was andere GUI-Rahmenwerke schon mitbringen ist viel. Insbesondere in einer ausdrucksstarken Programmiersprache.

Das was Du da machst ist Stümperei denn da fehlt der Nachweis das `event_generate()` threadsicher ist. Von den Tcl-Wikiseiten zum Thema „Tcl and threads“ und den Regeln für das einbetten von Tcl in eine Anwendung mit Threads: „You can NEVER use the same interpreter from more than one thread“. Die Hervorhebung ist *nicht* von mir, die steht da in gross und fett im Original, scheint also ernst gemeint und wichtig zu sein. Solange also `Tkinter` keine Garantien über das was Tk/Tcl nicht garantiert hinaus gibt, dürfte das erklären warum man immer nur so ”stümperhafte” Polling-Beispiele mit Queue und `after()` findet: Das ist halt das einzige was tatsächlich threadsicher funktioniert. Die einzige Möglichkeit ist also schlecht. Okay…

[Alfons Mittelmeyer]

Von den Tcl-Wikiseiten zum Thema „Tcl and threads“ und den Regeln für das einbetten von Tcl in eine Anwendung mit Threads: „You can NEVER use the same interpreter from more than one thread“.

Genau darum geht es, dass eben durch das Event die Funktion nicht von der andern Task ausgeführt wird, sondern dann erst von der GUI, wenn sie dran ist. Hier steht etwas über event_generate: Tkinter: is event_generate safe from background thread?

Und ein Eric Brunel hatte genau dasselbe getan, wie ich hier tue. Dann geht es um die Frage, ob event_generate threadsicher ist.

event_generate so zu benutzen ist falsch: app.event_generate("<<myevent1>>")
Hier wird nämlich das Event unmittelbar ausgeführt, ohne in die GUI Task zu wechseln.

Aber so ist es richtig: app.event_generate("<<myevent1>>", when='tail')
Hier wird das Event in die tkinter Event Queue geschrieben. Und in dieser Form ist event_generate threadsicher.

Eric Brunel hatte das dazu geschrieben:

This is where the problem is: if you do just a event_generate without
specifying the 'when' option, the binding is fired immediately in the
current thread. To be sure that an event is created and that the thread
switch actually happens, do:

app.event_generate("<<myevent1>>", when='tail')

and things should work fine.

Quelle: http://bytes.com/topic/python/answers/5 ... er-threads

Und wenn Du es genau wissen willst, musst Du Dir the Tcl/Tk Dokumentation durchlesen: http://www.tcl.tk/man/

Also hier ist die Doku:

event generate window event ?option value option value ...?
Generates a window event and arranges for it to be processed just as if it had come from the window system. Window gives the path name of the window for which the event will be generated; it may also be an identifier (such as returned by winfo id) as long as it is for a window in the current application. Event provides a basic description of the event, such as <Shift-Button-2> or <<Paste>>. If Window is empty the whole screen is meant, and coordinates are relative to the screen. Event may have any of the forms allowed for the sequence argument of the bind command except that it must consist of a single event pattern, not a sequence. Option-value pairs may be used to specify additional attributes of the event, such as the x and y mouse position; see EVENT FIELDS below. If the -when option is not specified, the event is processed immediately: all of the handlers for the event will complete before the event generate command returns. If the -when option is specified then it determines when the event is processed. Certain events, such as key events, require that the window has focus to receive the event properly.

-when When determines when the event will be processed; it must have one of the following values:

now
Process the event immediately, before the command returns. This also happens if the -when option is omitted.

tail
Place the event on Tcl's event queue behind any events already queued for this application.

head
Place the event at the front of Tcl's event queue, so that it will be handled before any other events already queued.

mark
Place the event at the front of Tcl's event queue but behind any other events already queued with -when mark. This option is useful when generating a series of events that should be processed in order but at the front of the queue.

Quelle: https://www.tcl.tk/man/tcl/TkCmd/event.htm

[jerch]

@Alfons Mittelmeyer: Ob der Threadkontext gewechselt wurde, kannst Du mit `threading.currentThread()` überprüfen. In callbacks, die die GUI manipulieren, sollte dort der GUI-Thread (idR der MainThread) auftauchen.
Bei Qt z.B. muss man höllisch aufpassen, was Signal- und Eventauslieferung über mehrere Threads angeht. So muss man dort einen Eventloop in Subthreads explizit starten, damit überhaupt die Auslieferung von Mainthread nach Subthread funktioniert. KA, inwiefern Tkinter sowas unterstützt.

[Alfons Mittelmeyer]

Und was professionelle Softwareedntwickler überprüft haben: after und after_idle nicht threadsicher. Nur event_generate threadsicher!

Hi,

afaik the after() / after_idle() calls are not thread safe!

On my research leading to the code Andreas provide I found the
event_generate() method the only threadsafe way to invoke the tk
thread without letting it poll something. (As mentioned by Guido and
seen on other pages everyone else seems to poll... why?)

brgds,

-- Jan

Quelle: https://mail.python.org/pipermail/tkint ... 03522.html

Und Jan Uebernickel wundert sich auch, warum anscheinend fast alle after nehmen und pollen. Muss wohl an 'sogenannten Experten' liegen, die Nonsens verbreiten.

Was hat Guido van Rossum geschrieben?

> I've tried other things:
>
> - createfilehandler: This says it cannot work when Tcl/Tk is threaded and it
> will be removed in Python 3 anyway.
>
> - The bg thread can use after_idle() or after() to run a command on the Tk
> object; this works, but it doesn't seem to wake up the Tk main loop -- the
> command usually only runs when I cause a UI event to be generated (e.g.
> selecting the window).
>
> What other solutions could I try? I really don't like the "after(100,
> <repeat>)" solution.
>
> --
> --Guido van Rossum (python.org/~guido)

Selbe Quelle wie vorher.

Also Probleme mit after und after_idle

[BlackJack]

@Alfons Mittelmeyer: Durch ``when='tail'`` wird das Ereignis an das Ende der Warteschlange gesetzt, das garantiert aber nicht das diese Operation threadsicher ist, denn diese Warteschlange wird in dem Augenblick von zwei Threads aus manipuliert. Und Tcl ist nicht threadsicher. Was garantiert dann also in diesem Fall Deiner Meinung nach die Threadsicherheit? Das das Eric Brunel 2006 scheinbar unter drei Betriebssystemen nicht offensichtlich auf die Nase gefallen ist, macht das ganze nicht threadsicher. Die Aussage „[…] and things should work fine.” auch nicht.

Da Du ja auf die offizielle Tcl/Tk-Dokumentation verwiesen hast, daraus ein Auszug: „An important constraint of the Tcl threads implementation is that only the thread that created a Tcl interpreter can use that interpreter. In other words, multiple threads can not access the same Tcl interpreter.“

Auch hier ist die Hervorhebung wieder aus dem Original übernommen und nicht von mir.

Wenn Du also `event_generate()` aus einem anderen Thread heraus verwendest musst Du auch stichhaltig begründen können warum das sicher sein soll obwohl die Dokumentation ausdrücklich sagt dass das nicht vorgesehen ist. Ein „aber bis jetzt ist nichts schlimmes passiert“ reicht da nicht. Insbesondere nicht mit einer Python-Implementierung mit GIL, denn sollte *das* der Grund sein warum es ”funktioniert” dann baust Du auf Sand.

Deine Implementierung ist falsch, da fehlerhaft, da sie auf falschen Annahmen aufbaut.

[Alfons Mittelmeyer]

@BlackJack Komisch dass Du meinst, Du wüsstest es besser als Guido van Rossum, sodass Du sagen kannst, was der schreibt, ist falsch.

Und kapieren tust Du anscheinend auch nichts, weshalb Du das ständig wiederholst:

Da Du ja auf die offizielle Tcl/Tk-Dokumentation verwiesen hast, daraus ein Auszug: „An important constraint of the Tcl threads implementation is that only the thread that created a Tcl interpreter can use that interpreter. In other words, multiple threads can not access the same Tcl interpreter.“

Deshalb benutzt man ja event_generate, damit nicht die andere Task die Tcl Kommandos ausführt, sondern nur ein Event in die Tcl Event Queue geschrieben wird. Wenn dann der Tcl Interpreter wieder dran ist, dann führt dieser die damit verbundene Funktion aus. Begreifen fällt Dir anscheinend schwer.

[BlackJack]

@Alfons Mittelmeyer: Wo kommt denn jetzt van Rossum ins Spiel? Komisch da Du mal wieder meinst es besser zu wissen als die Dokumentation. Und hier kommt es nicht auf Meinungen an: Zeig einfach technisch nachvollziehbar auf warum das threadsicher sein soll unter der Annahme das Tcl/Tk das nicht ist. Das wäre dann ja problemlos möglich. Was genau sichert von der Python-Anbindung aus den Tcl/Tk-internen Zugriff auf dessen Ereigniswarteschlange ab?

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: Wo kommt denn jetzt van Rossum ins Spiel?

Lesen kannst Du anscheinend auch nicht, denn ich hatte einen Auszug gepostet, gezeichnet mit "--Guido van Rossum (python.org/~guido)". Also hier nochmals: https://mail.python.org/pipermail/tkint ... 03522.html

[sparrow]

@Alfons Mittelmeyer: Wo kommt denn jetzt van Rossum ins Spiel?

Lesen kannst Du anscheinend auch nicht, denn ich hatte einen Auszug gepostet, gezeichnet mit "--Guido van Rossum (python.org/~guido)". Also hier nochmals: https://mail.python.org/pipermail/tkint ... 03522.html

Oh mein Gott. 100 Jahre Programmiererfahrung und nicht in der Lage auf einer Mailingliste zu sehen wer derjenige ist, der fragt?

[jerch]

@Alfons:
Wie alt bist Du eigentlich? Die Angriffe auf Personen stärken nicht Deine Argumente sondern machen DICH lächerlich. Dachte eigentlich, Du hättest meine Anspielung weiter oben verstanden, aber das Sandkastenniveau musste wohl trotzdem her.

1+ fürs Sperren.