On lun, 2014-06-23 at 11:45 +0530, diliup gabadamudalige wrote: > I called event.clear() cause it says in the Pygame documentation that > if you leave unused events on the buffer that eventually it may fill > up and cause the program to crash.
Yes, but if you are getting everything from the buffer using event.get() or whatever every frame, then it's not going to fill up, as these returned events are removed from the queue. As long as you are reading the whole buffer, say every 100ms, you're going to be fine. Otherwise, you're just throwing away the events that have arrived between the event.get() and event.clear() calls. > > if x is True: > is not correct > > if x == True > is correct? This obviously depends on what x is. So, if we write: "foo" is True We can clearly see these are not the same object. One is a string, and the other is the True object. But, if we do: "foo" == True Then, we are asking if the string evaluates to a True value, when treated as a boolean. And any non-empty string will be considered True, and so it is equal to True (but not the same object). Futhermore, what Greg was saying is that some objects can be of the same value and still not be the same object. Thus: a = 4040 b = 4040 a == b # True a is b # Could be False b = a # b now references the a object itself a is b # Always True This becomes more obvious if we were to use mutable types: a = [2] b = [2] # Obviously, these are two distinct objects a == b # True a is b # False # Changing one, would not change the other, as they are different # objects. a.append(3) a == b # False On an interesting sidenote, it is not even required that an object is equal to itself: a = float("NaN") a == a # False
signature.asc
Description: This is a digitally signed message part