sleep oder so

[KenderGuru]

ich würde gerne ein kleines spiel programmieren und wollte eine sperre einbauen damit nach jedem tastendruck 0.2 sekunden nichts passiert wenn eine weitere taste gedrückt wird, sleep funktioniert nicht

import random
from time import sleep
import pygame, sys
from pygame.locals import *

pygame.init()
DISPLAY = pygame.display.set_mode((861.5, 830.5))
pygame.display.set_caption("Spiel")

GRAU = (115, 115, 115)
WEISS = (255, 255, 255)
ROT = (255, 0, 0)
GRUENWIESE = (0, 255, 0)
GRUENBAUM = (0, 139, 0)
SCHWARZ = (0, 0, 0)
BLAU = (0, 0, 205)
DISPLAY.fill(WEISS)

characterx = 0
charactery = 0

clock = pygame.time.Clock()

while True:
for event in pygame.event.get():
if event.type == QUIT:
pygame.quit()
sys.exit()

elif event.type == KEYDOWN:
if event.key == K_LEFT:
characterx = characterx - 54.25
elif event.key == K_RIGHT:
characterx = characterx + 54.25
elif event.key == K_DOWN:
charactery = charactery + 52.0625
elif event.key == K_UP:
charactery = charactery - 52.0625


welt1 = pygame.image.load('welt_1.png')
welt_1 = pygame.transform.scale(welt1, (868, 833))
DISPLAY.blit(welt_1, (0, 0))


characterbild = pygame.image.load('rezo.jpg')
character = pygame.transform.scale(characterbild, (108.5, 104.125))
DISPLAY.blit(character, (characterx, charactery))







pygame.display.update()

[Onomatopoesie]

Zeitstempel setzen. Beim nächsten Schleifendurchlauf überprüfen, ob die aktuelle Zeit >= Zeitstempel + 200 ist. Falls ja: Befehl ausführen. Falls nicht, nichts machen.
Könnte das die Lösung sein?

[__deets__]

Sowas ist die Loesung, ja.

[LukeNukem]

Sowas ist die Loesung, ja.

Die von Pygame vorgesehenen Lösungen scheinen die Funktionen pygame.time.wait() [1] und pygame.time.sleep() [2] zu sein.

[1] https://www.pygame.org/docs/ref/time.ht ... .time.wait
[2] https://www.pygame.org/docs/ref/time.ht ... time.delay

[__deets__]

Nein. Hier geht es darum, dass das Programm weiterläuft, und nur für einen gewissen Zeitraum eine bestimme Eingabe unterdrückt wird. Nicht darum, den programmablauf für mehrere hundert ms zu unterbrechen. Das tun aber deine Funktionen.

[LukeNukem]

Nein. Hier geht es darum, dass das Programm weiterläuft, und nur für einen gewissen Zeitraum eine bestimme Eingabe unterdrückt wird.

Wie kommst Du darauf? Das kann ich aus der Frage des TO nämlich nicht erkennen, da steht, daß "nichts passieren" soll.

Nicht darum, den programmablauf für mehrere hundert ms zu unterbrechen. Das tun aber deine Funktionen.

Es ist zwar nicht meine Funktion, aber ja, das tut sie.

[sparrow]

@Luke Nukem: Es ist erstaunlich, wie sich die Deutung von Sätzen ändert, wenn man sie nicht nur partiell liest, oder? Da steht nämlich nicht "nichts passieren soll" sondern "nichts passiert wenn eine weitere taste gedrückt wird".

[__deets__]

Nicht nur das das da steht, da steht noch mehr: sleep funktioniert nicht. Womit die beiden genannten Funktionen, die semantisch nahezu oder sogar komplett gleich sind, schonmal nicht die Loesung darstellen.

Denn wait ist https://github.com/pygame/pygame/blob/6 ... ime.c#L282, und das ist https://github.com/zielmicha/SDL2/blob/ ... mer.c#L119, und das ist funktional identisch zu https://github.com/python/cpython/blob/ ... le.c#L2147

[LukeNukem]

@Luke Nukem: Es ist erstaunlich, wie sich die Deutung von Sätzen ändert, wenn man sie nicht nur partiell liest, oder? Da steht nämlich nicht "nichts passieren soll" sondern "nichts passiert wenn eine weitere taste gedrückt wird".

So wie ich das lese, soll das Programm im spezifizierten Zeitraum nur nicht auf weitere Tastendrücke reagieren. Davon, daß das Programm unterdessen weiterlaufen soll, lese ich hingegen nichts. Ich sehe auch nicht, daß der Code des TO irgendetwas enthält, das auf Parallelisierung, Concurrency oder irgend etwas in der Art hindeuten würde; obendrein schreibt der TO, daß er das gewünschte Verhalten mit time.sleep() implementieren wollte, das den aufrufenden Thread meines Wissens üblicherweise schlafen legt. Genau das tun im pygame-Universum die von mir verlinkten Funktionen, wenn ich die Dokumentation richtig verstehe. All das deutet für mich ohne weitere Informationen nicht darauf hin, daß ein Weiterlaufen des Programms während der Wartezeit gewünscht oder erforderlich ist. Aber vielleicht bin ich ja doof oder habe noch etwas überlesen, das Dir aufgefallen ist, dann bitte ich um einen kurzen, aber deutlichen Hinweis. Vielen lieben Dank dafür!

Nebenbei bemerkt, habe ich die Geschichte jetzt einmal ausprobiert: man kann das Programm mit den oben von mir verlinkten Funktionen oder mit time.sleep() (ja, das funktioniert hier bei mir) schlafen legen. Dann findet zwar keine sichtbare Interaktion beim Programm, aber die Event-Queue wird trotzdem weiter befüllt und abgearbeitet, sobald der nächste Lauf der for-Schleife beginnt. Deswegen muß die Event-Queue nach dem Schlafen einmal mit pygame.event.get() geflusht werden und ist dann (ausgenommen natürlich neue Events, die während der Zeichenoperationen ausgelöst werden) wieder leer, wenn der nächste Aufruf von pygame.event.get() anfangs der for-Schleife wieder aufgerufen wird.

[__deets__]

Der deutliche Hinweis den du vermisst ist von mir schon gegeben worden. "sleep funktioniert nicht" sagt der TE.

Und aus der Erfahrung weiss man ja auch, dass genau solche Dinge den Leuten Probleme machen. An allen Ecken und enden. Sie wollen etwas verzoegern, aber gleichzeitig soll das Programm weiterlaufen. Und daraus ergibt sich die Loesung, einen Zeitpunkt in der Zukunft zu definieren, und ein bestimmtes Verhalten davon abhaengig zu machen, ob der schon erreicht ist.

[LukeNukem]

Der deutliche Hinweis den du vermisst ist von mir schon gegeben worden. "sleep funktioniert nicht" sagt der TE.

Richtig, und mehr sagt der TO auch nicht dazu.

Und aus der Erfahrung weiss man ja auch, dass genau solche Dinge den Leuten Probleme machen. An allen Ecken und enden. Sie wollen etwas verzoegern, aber gleichzeitig soll das Programm weiterlaufen.

Das ist Eure Annahme aufgrund von Euren Erfahrungen. Leider befürchte ich trotzdem, daß sie in diesem Falle falsch ist -- denn in den Aussagen und dem Code des TO sehe ich nichts, das diese Annahme erhärten würde. Was soll denn da bitte weiterlaufen? Siehst Du da irgendwelchen Code, der das könnte? Vielleicht habe ich den ja übersehen, dann gib mir doch bitte einen Hinweis.

Meine Überlegung (und ein darauf folgender praktischer Versuch) lassen jedoch zumindest die starke Vermutung zu, daß time.sleep für den TO genau deswegen nicht funktioniert, weil eventuelle Events dann weiterhin in der Event-Queue landen, eben auch während das Programm in seiner "Ruhepause" verharrt. Wenn der Benutzer innerhalb dieser "Ruhephase" eine Taste drückt, landet der Tastendruck also dennoch in der Event-Queue. Beim nächsten Lauf der For-Schleife werden diese unerwünschten Events dann aus der Event-Queue abgearbeitet. Dies wiederum führt dazu, daß das "charakterbild" dann (in Abhängigkeit von den Tastendrücken während der Ruhephase) mehrere Schritte weit (und womöglich sogar in verschiedene Richtungen) springt -- eben so weit und dorthin, wie der Benutzer während der "Ruhephase" auf seine Tasten gedrückt hat. Auch das ist ein Verhalten, das unser TO mit seiner knappen Aussage "sleep funktioniert nicht" gemeint haben könnte. Ehrlich gesagt, halte ich das sogar für die wahrscheinlichste Variante -- dies insbesondere auch, weil ich bisher keinen Code sehe, der während der "Ruhephase" laufen würde oder auch nur könnte.

Wenn ich spitzfindig wäre, würde ich sogar behaupten, daß das Gegenteil der oben erwähnten und zweifellos wohlwollenden Annahme zutrifft. Das Problem des TO wäre dann nicht, daß das Programm während besagter Ruhephase nicht weiterläuft, sondern im Gegenteil, daß es weiterläuft -- nämlich insofern, als die Event-Queue während der "Ruhephase" weiterhin Events annimmt. Wenn diese (nicht auf Euren Erfahrungen, sondern auf meinen Beobachtungen fußende) Annahme zutrifft, läßt sich das Problem offensichtlich leider auch nicht ohne Weiteres mit der von Onomatopoesie vorgeschlagenen Lösung beheben, denn die Events würden auch dabei während seiner Wartezeit (und der vermuteten Abarbeitung des ominösen Geistercodes) in der Event-Queue landen, und müßten daher also verworfen werden. Überraschung: zum Glück bin ich gar nicht spitzfindig.

Das beschriebene Verhalten konnte ich hier sowohl mit time.sleep als auch mit pygame.time.wait nachstellen. Um es zu verhindern, ist es -- wie ich bereits in meinem vorherigen Beitrag erläutert habe -- notwendig, daß die Event-Queue entweder während der "Ruhephase" blockiert, oder nach ihrem Ende geleert und die während der Ruhephase angefallenen Events verworfen werden. Da ich in der Dokumentation von pygame aber keine Befehle zum Blockieren und / oder Flushen der Event-Queue gefunden habe, leere ich die Event-Queue stattdessen mit einem Aufruf von pygame.event.get an geeigneter Stelle, und schon sind die unerwünschten Events weg.

Damit wir alle hier wissen, worüber wir reden, stelle ich hier mal meinen leicht veränderten Code des TO ein; zur Verdeutlichung habe ich mir erlaubt, die Zeit der "Ruhepause" etwas zu erhöhen und alle Events am Anfang des Körpers der For-Schleife auszugeben. Meine Änderungen finden sich in Zeile 29 für die Ausgabe des Events sowie in den Zeilen 43 bis 45. Wenn Zeile 45 (pygame.event.get) auskommentiert wird, zeigt sich das erwähnte (und wie ich vermute, unerwünschte) Verhalten, daß nämlich die Events auch während der "Ruhepause" in der Event-Queue landen und dann natürlich vom nächsten Aufruf der For-Schleife abgearbeitet werden.

Code: Alles auswählen

#!/usr/bin/env python

import random
from time import sleep
import pygame, sys
from pygame.locals import *

pygame.init()
DISPLAY = pygame.display.set_mode((861.5, 830.5))
pygame.display.set_caption("Spiel")

GRAU = (115, 115, 115)
WEISS = (255, 255, 255)
ROT = (255, 0, 0)
GRUENWIESE = (0, 255, 0)
GRUENBAUM = (0, 139, 0)
SCHWARZ = (0, 0, 0)
BLAU = (0, 0, 205)
DISPLAY.fill(WEISS)

characterx = 0
charactery = 0

clock = pygame.time.Clock()


while True:
    for event in pygame.event.get():
        print(event)
        if event.type == QUIT:
            pygame.quit()
            sys.exit()

        elif event.type == KEYDOWN:
            if event.key == K_LEFT:
                characterx = characterx - 54.25
            elif event.key == K_RIGHT:
                characterx = characterx + 54.25
            elif event.key == K_DOWN:
                charactery = charactery + 52.0625
            elif event.key == K_UP:
                charactery = charactery - 52.0625
            #sleep(1)
            pygame.time.wait(1000)
            pygame.event.get()
            
    welt1 = pygame.image.load('welt_1.png')
    welt_1 = pygame.transform.scale(welt1, (868, 833))
    DISPLAY.blit(welt_1, (0, 0))
    
    characterbild = pygame.image.load('rezo.jpg')
    character = pygame.transform.scale(characterbild, (108.5, 104.125))
    DISPLAY.blit(character, (characterx, charactery))

    pygame.display.update()    

Viel Vergnügen!

[__deets__]

Der deutliche Hinweis den du vermisst ist von mir schon gegeben worden. "sleep funktioniert nicht" sagt der TE.

Richtig, und mehr sagt der TO auch nicht dazu.

Trotzdem schliesst das schonmal deine Funktionen aus, denn die sind ja nun gleich, wie schon belegt wurde.

Das ist Eure Annahme aufgrund von Euren Erfahrungen. Leider befürchte ich trotzdem, daß sie in diesem Falle falsch ist -- denn in den Aussagen und dem Code des TO sehe ich nichts, das diese Annahme erhärten würde. Was soll denn da bitte weiterlaufen? Siehst Du da irgendwelchen Code, der das könnte? Vielleicht habe ich den ja übersehen, dann gib mir doch bitte einen Hinweis.

Also um das mal klarzukriegen: dein Argument hier ist, dass nur was man im Code sieht dazu berechtigt, Vermutungen ueber die eigentlich gewuenschte Funktion anzustellen? Alles andere ist verboten?

Ich finde das ja schon ein bisschen ulkig, dass du an anderer Stelle (und quasi zeitgleich) argumentierst, dass man ja *aus Erfahrung* weiss, dass man OO fuer GUIs braucht, und darum auch OO benutzen sollte, selbst wenn gerade ganz akut eigentlich kein Grund dazu besteht.

Meine Überlegung (und ein darauf folgender praktischer Versuch) lassen jedoch zumindest die starke Vermutung zu, daß time.sleep für den TO genau deswegen nicht funktioniert, weil eventuelle Events dann weiterhin in der Event-Queue landen, eben auch während das Programm in seiner "Ruhepause" verharrt.

Vorzuschlagen, dass man die Event Queue leert, statt einfach nur die *Verarbeitung* der spezifischen Events fuer die Spielerkontrolle oder was auch immer nicht zu behandeln, ist schlicht absurd. Spieleprogrammierung hat ueblicherweise einen laufenden Loop, in dem dann alles moegliche passiert, zB auch Animationsphasen abzuarbeiten und so weiter.

Sieht man die im Code? Nein. Ist es trotzdem ein uebliches Vorgehen. Unueblich hingegen ist, einfach die Events (die ja zb auch ein QUIT-event sein koennen) einfach zeitweise *komplett* zu ignorieren.

Tut mir leid, aber du rechtfertigst hier einfach nur die Richtung, in die du dich vergallopiert hast. Events einfach wegzuschmeissen ist keine Loesung. Es ist bestenfalls ein komischer Workaround.

[LukeNukem]

Trotzdem schliesst das schonmal deine Funktionen aus, denn die sind ja nun gleich, wie schon belegt wurde.

Es sind immer noch nicht meine Funktionen. Zudem habe ich eine funktionsfähige Lösung mit einer dieser Funktionen vorgelegt, die die Forderungen des TO präzise erfüllt. Dennoch zu behaupten, daß diese Funktionen ausgeschlossen seien... Pardon, das ist absurd. Hast Du ausprobiert, was ich in meinem letzten Beitrag vorgeschlagen hatte?

Also um das mal klarzukriegen: dein Argument hier ist, dass nur was man im Code sieht dazu berechtigt, Vermutungen ueber die eigentlich gewuenschte Funktion anzustellen? Alles andere ist verboten?

Mein Argument ist, daß der TO hier Aussagen getroffen und Code gezeigt hat, die einerseits meinen Lösungsvorschlag nahe legen und andererseits nicht einmal vage Indizien für Deine Annahmen liefern.

Sieht man die im Code? Nein. Ist es trotzdem ein uebliches Vorgehen. Unueblich hingegen ist, einfach die Events (die ja zb auch ein QUIT-event sein koennen) einfach zeitweise *komplett* zu ignorieren.

Tut mir leid, aber du rechtfertigst hier einfach nur die Richtung, in die du dich vergallopiert hast. Events einfach wegzuschmeissen ist keine Loesung. Es ist bestenfalls ein komischer Workaround.

Wenn "Events wegzuschmeißen" ja "keine Lösung" sein soll, warum hat pygame genau dafür sogar extra die Funktion pygame.event.clear? (Sorry, die habe ich gerade erst entdeckt.)

Kannst Du mir bitte verraten, warum Du hier so emotional und unsachlich wirst, obwohl ich lediglich eine andere Lösung mit den Mitteln des verwendeten Frameworks präsentiert habe? Danke.

[__deets__]

“Deine Funktionen” steht für “die von dir vorgeschlagenen Funktionen”, und das weißt du auch, wenn du nicht versuchst, Wortklauberei zu betreiben.

Das deine Lösung in irgendeiner Form näher liegen würde, und es keine Indizien für meine gäbe, ist aus dem Code und der Problembeschreibung genauso nicht ersichtlich. Denn da steht “auf Tastendruck nichts passiert”. Nicht “auf nichts was irgendwie ein Event ist etwas passiert”. Im Gegenteil: da wird ein QUIT Event genutzt. Und das schluckst du auch einfach ungefragt weg, mit clear. Wo bitte ist dein Indiz dafür, das wäre gewünscht?

Und eine Lösung vorzuschlagen, die in ihren Konsequenzen deutlich weiter geht, statt einer, die das spezifische Problem löst, ist eben schlechter. Das Argument, dass sie geeignet (oder gar geeigneter, wie du es ja behauptest) wäre, weil es eine clear Funktion gibt, ist ein Strohmannargument. Es gibt in Python auch das global keyword. Darum ist üblicherweise eine Lösung eines Problems unter Verwendung von global trotzdem nicht die bessere Lösung.

Das ich unsachlich argumentiere, aber du sachlich ist auch mal wieder so ein Ding. Du bezeichnest meinen (bzw unseren Vorschlag) als “falsch”. Eine Qualifizierung, der du dich an anderer Stelle vehement verwehrst, aber mit Leichtigkeit selbst nutzt. Aha. Die neue Sachlichkeit.

[LukeNukem]

“Deine Funktionen” steht für “die von dir vorgeschlagenen Funktionen”, und das weißt du auch, wenn du nicht versuchst, Wortklauberei zu betreiben.

Entschuldige, Wortklauberei liegt mir fern. Allerdings möchte ich mich auch nicht mit fremdem Federn schmücken und darum nicht mit dem Pygame-Projekt assoziiert werden, mit dem ich nichts zu tun habe.

Das deine Lösung in irgendeiner Form näher liegen würde, und es keine Indizien für meine gäbe, ist aus dem Code und der Problembeschreibung genauso nicht ersichtlich. Denn da steht “auf Tastendruck nichts passiert”. Nicht “auf nichts was irgendwie ein Event ist etwas passiert”. Im Gegenteil: da wird ein QUIT Event genutzt. Und das schluckst du auch einfach ungefragt weg, mit clear. Wo bitte ist dein Indiz dafür, das wäre gewünscht?

Stimmt, da hast Du natürlich Recht. Anstatt die Event-Queue zu leeren ist es vielleicht sinnvoller, nach der Ruhephase die Event-Queue einmal mit pygame.event.get abzurufen, die KEYDOWN-Events zu filtern und alle anderen wieder in die Queue zu posten (pygame.event.post). Dennoch werden in der Wartezeit von pyevent.time.wait und pyevent.time.delay keine Events behandelt, auch nicht das QUIT--Event. Das finde ich bei einem Zeitraum von 200ms nun noch nicht problematisch, aber bei einer längeren Ruhephase könnte das womöglich stören und man müßte sich eine andere Lösung überlegen.

Nach etwas mehr Nachdenken glaube ich mittlerweile aber noch weniger, daß die von Euch vorgeschlagene Lösung paßt. Denn pygame.event.get blockiert, solange keine Events in der Event-Queue vorliegen, was im Umkehrschluß bedeutet: solange keine neuen Events vorliegen, hängt das Programm unweigerlich in pygame.event.get fest. Euer Vorschlag kann daher nur funktionieren, wenn entweder Events stattfinden (okay, die könnte man periodisch mit pygame.time.set_timer erzeugen,) oder wenn ein zweiter Thread oder Prozess gestartet wird, der sich seinerseits um das Polling der Systemzeit kümmert und den Ablauf der Ruhephase signalisiert.

Und eine Lösung vorzuschlagen, die in ihren Konsequenzen deutlich weiter geht, statt einer, die das spezifische Problem löst, ist eben schlechter. Das Argument, dass sie geeignet (oder gar geeigneter, wie du es ja behauptest) wäre, weil es eine clear Funktion gibt, ist ein Strohmannargument. Es gibt in Python auch das global keyword. Darum ist üblicherweise eine Lösung eines Problems unter Verwendung von global trotzdem nicht die bessere Lösung.

Ach, nicht alles, was hinkt, ist ein Vergleich... Aber dennoch vertrete ich die (womöglich unpopuläre) Auffassung, daß man die vorgesehenen Features eines Framework nicht nur nutzen darf, sondern auch sollte, wenn man sich schon für dieses Framework entschieden hat. Das sehen wir hier ja manchmal in den tkinter-Threads -- sogar das Kernproblem ist ähnlich: in beiden Fällen geht es um ereignisgesteuerte Architekturen, und das ist auch der Grund, warum Euer Vorschlag nur unter bestimmten Umständen funktionieren kann (siehe dazu meinen vorherigen Absatz).

Das ich unsachlich argumentiere, aber du sachlich ist auch mal wieder so ein Ding. Du bezeichnest meinen (bzw unseren Vorschlag) als “falsch”. Eine Qualifizierung, der du dich an anderer Stelle vehement verwehrst, aber mit Leichtigkeit selbst nutzt. Aha. Die neue Sachlichkeit.

Bitte lies etwas genauer: das "falsch" bezog sich offensichtlich auf das Substantiv des vorangegangenen Satzes, mithin: "Eure Annahme" -- also im Wesentlichen die Annahme, daß während der "Ruhephase" noch etwas geschehen solle. Diese Annahme beruht nur auf Vermutungen, welche jedoch weder die Aussagen des TO, noch sein Code hergeben.

[__blackjack__]

Ich vermute Du fasst den Lösungsvorschlag falsch auf. Das `event.get()` blockiert spielt keine Rolle, da muss auch kein Ende signalisiert werden. Der Endzeitpunkt der Pause wird in einer Variablen gespeichert und daran kann man zu jedem Zeitpunkt feststellen ob man sich noch in der Pause befindet oder schon danach. Es soll ja nicht genau zu dem Zeitpunkt etwas passieren, also ist das auch egal wie lange der `get()`-Aufruf blockiert.

[__deets__]

Diese (notduerfdig umgearbeitete) Version des Programms des TE illustriert, wie das Prinzip funktioniert.

Code: Alles auswählen

wimport time
import pygame, sys
from pygame.locals import *

pygame.init()
DISPLAY = pygame.display.set_mode((861, 830))
pygame.display.set_caption("Spiel")

PAUSE = 2

GRAU = (115, 115, 115)
WEISS = (255, 255, 255)
ROT = (255, 0, 0)
GRUENWIESE = (0, 255, 0)
GRUENBAUM = (0, 139, 0)
SCHWARZ = (0, 0, 0)
BLAU = (0, 0, 205)
DISPLAY.fill(WEISS)

characterx = 0
charactery = 0

clock = pygame.time.Clock()

welt_1 = pygame.Surface((868, 833))
welt_1.fill((0, 255, 0))

character = pygame.Surface((108, 104))
character.fill((0, 0, 255))

timestamp = time.monotonic() - PAUSE
while True:
    for event in pygame.event.get():
        if event.type == QUIT:
            pygame.quit()
            sys.exit()

        elif event.type == KEYDOWN:
            if timestamp <= time.monotonic():
                if event.key == K_LEFT:
                    timestamp = time.monotonic() + PAUSE
                    characterx = characterx - 54.25
                elif event.key == K_RIGHT:
                    characterx = characterx + 54.25
                    timestamp = time.monotonic() + PAUSE
                elif event.key == K_DOWN:
                    charactery = charactery + 52.0625
                    timestamp = time.monotonic() + PAUSE
                elif event.key == K_UP:
                    charactery = charactery - 52.0625
                    timestamp = time.monotonic() + PAUSE

    DISPLAY.blit(welt_1, (0, 0))

    DISPLAY.blit(character, (characterx, charactery))
    pygame.display.update()

Ich habe die Pause kuenstlich erhoeht, weil die 0.2 schon recht knapp bestimmt sind.

Es funktioniert genauso, wie der TE sich das wuenscht. Fuer einen gegeben Zeitraum werden *Tastendruecke* unterdrueckt. Das Programm beenden kann man immer noch. Ich weiss nicht, wie du zur der Annahme kommst, unsere/meine Annahme waere falsch, aber diese Annahme ist ... falsch.

Wie __blackjack__ ja schon ausgefuehrt hat, ist es egal, woher das Ereignis kommt. Momentan ist es immer ein Ereignis, durch die blockierende Natur von get(), welches das Programm weiter treibt. Ob der Timestamp in der Zwischenzeit ueberschritten wurde, ist irrelevant.