Re: Re: [pygame] BUG: pygame.event.peek

["Brian Fisher" <brian@xxxxxxxxxxxxxxxxxxx>]

On 7/31/06, Taylor Boon <tboon@xxxxxxxxxxx> 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.
according to the bug report by Alex earlier in this thread, the docs
(http://www.pygame.org/docs/ref/event.html#pygame.event.peek) say peek
with no arguments returns bool, but for him, it was getting the
event... so by the docs it doesn't get the event, by the
implementation it does...

so to use your terminology, it's thread safe by documentation, thread
unsafe by implementation


> peek is useful in order to service events while also doing other processing.
>
> Another use that comes to mind is to yield time to other processes,
> something like this (pseudo code again):
>
> A final example uses peek's abaility to just see if certain event types are
> in the event queue:
I notice that for your examples of the usefulness of peek (all great
examples), in each case peek was returning a bool, not the event
itself, so the "undocumented" behavior isn't needed there

I haven't seen anyone on this thread say that either:
a) the undocumented behavior of returning an event is useful
b) the documented behavior of returning a bool is unsafe

so it seems fixing the code to match the docs (peek with no args
returns a bool) would be the right thing... is there anyone who thinks
otherwise?