Taylor Boon wrote:
This does not appear to be the case. Check out the
"pygame+threading+windows" thread on this list. Other threads can't "get"
an event behind your back because they cannot get an event. So, perhaps
by accident rather than design, peek is thread safe.
peek is useful in order to service events while also doing other
processing. Pseudocode:
while not done:
#each part will take a second or two
do_part_of_a_long_computation()
#service events if there are any, otherwise do another part
# of the long computation...
if event.peek():
for event in event.get():
process_event(event)
This is equivalent to:
while not done:
#each part will take a second or two
do_part_of_a_long_computation()
#service events if there are any, otherwise do another part
# of the long computation...
for event in event.get():
process_event(event)
Another use that comes to mind is to yield time to other processes,
something like this (pseudo code again):
while running:
if not event.peek():
#let something else run for a bit...
sleep(1)
else:
process_events()
In the current implementation this will not do what you expect, as
event.peek() returns an event, not a bool. If there are no events in the
queue, an event filled with uninitialized data will be returned (not None,
as you might hope).
A final example uses peek's abaility to just see if certain event types
are in the event queue:
#assumes pygame.locals imported
while app.running:
#process mouse events only
if event.peek([MOUSEMOTION, MOUSEDOWN, MOUSEUP])
do_mouse_things()
#don't care about other events...
peek has its place.
You haven't demonstrated valid use of the undocumented form of peek:
'peek() -> Event', only the documented one: 'peek([events]) -> bool'.
There's no reason to drop the documented behaviour, only the form
returning Event, which is undocumented, is buggy, and should either be
repaired or dropped.
Alex.
__________ NOD32 1.1685 (20060731) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com