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
Attachment:
signature.asc
Description: This is a digitally signed message part