On 7/31/06, Taylor Boon <[EMAIL PROTECTED]> 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?
