diliup gabadamudalige wrote:
for event in pygame.event.get([KEYDOWN, KEYUP, MOUSEMOTION, MOUSEBUTTONUP]):
so far works well. I also noted a slight increase in speed. Is that my
imagination or could specifying the events looked at speed up the process?
It's almost certainly your imagination.
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.
Also can you explain why
if x is True:
is not correct
and
if x == True
is correct?
On Mon, Jun 23, 2014 at 11:34 AM,
diliup gabadamudalige wrote:
Can someone please explain why
if event.type is KEYUP:
is bad and
if event.type == KEYUP:
is correct?
The 'is' operator tests whether two expressions refer to
the *same* object. It's possible for two different int
objects to have the same value, in which case
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.
What it says is:
If you are only taking specific events from the queue,
be aware
Im curious why is is bad in this case, as well. It's a constant; isn't
that a good use for is, whether it's referring to an int or not? I tend to
do this for event handling. Maybe ints are always pointers in python?
The caveat for events is just warning you that the queue could fill up if
you
I too was thinking on the lines of Noel on this matter. I actually read
this somewhere. If i can find it I will share it
On Mon, Jun 23, 2014 at 12:15 PM, Noel Garwick noel.garw...@gmail.com
wrote:
Im curious why is is bad in this case, as well. It's a constant; isn't
that a good use for is,
6 is 2 * 3
True
666 is 2 * 333
False
60 is 10 * 6
True
666 == 2 * 333
True
above is the result of my check
This is really weird!
I thought computers were absolute logic and didn't work like humans.
Looks like the programmers have included their idiosyncrasies to the
programs! Else how could this
when you say a=100 and b=100 it is understood that a and b are both given
TWO values and that both are the same is a coincidence.
BUT if that is the case how can a is b be TRUE for small integers and a is
b False for large integers? What logic is Python using here?
On Mon, Jun 23, 2014 at 1:07
On lun, 2014-06-23 at 02:45 -0400, Noel Garwick wrote:
Im curious why is is bad in this case, as well. It's a constant;
isn't that a good use for is, whether it's referring to an int or not?
I tend to do this for event handling. Maybe ints are always pointers
in python?
I was just about to
@diliup:
It's because python's* is *operator checks if the two item is the same, and
== checks for equality. Also python stores an object for the numbers from
-5 to 255 to speed up things.
Check it:
a = 255
b = 255
print a is b
print id(a), id(b)
a = 256
b = 256
print a is b
print id(a), id(b)
On lun, 2014-06-23 at 18:14 +1200, Greg Ewing wrote:
diliup gabadamudalige wrote:
for event in pygame.event.get([KEYDOWN, KEYUP, MOUSEMOTION, MOUSEBUTTONUP]):
so far works well. I also noted a slight increase in speed. Is that my
imagination or could specifying the events looked at
On lun, 2014-06-23 at 13:09 +0530, diliup gabadamudalige wrote:
when you say a=100 and b=100 it is understood that a and b are both
given TWO values and that both are the same is a coincidence.
BUT if that is the case how can a is b be TRUE for small integers and
a is b False for large
Thank you very much to all. Now very clear.
May you be well.
On Mon, Jun 23, 2014 at 1:27 PM, Sam Bull sam.hack...@sent.com wrote:
On lun, 2014-06-23 at 13:09 +0530, diliup gabadamudalige wrote:
when you say a=100 and b=100 it is understood that a and b are both
given TWO values and that
You're confused about what the 'is' operator and the '==' are. They aren't
the same thing. 'is' checks if two objects are the exact same objects.
Whereas '==' checks if they are equal objects.
Also I suggest using event.get() without specific types and ignoring event
types that you don't care
Try:
id(a), id(b)
In some cases they are different objects, and a is b rightly evaluates
to False.
Gumm
On 6/23/2014 00:39, diliup gabadamudalige wrote:
when you say a=100 and b=100 it is understood that a and b are both
given TWO values and that both are the same is a coincidence.
BUT if
OK EVERYONE.
If someone had read the python docs, they'd have known exactly why this
occurs. The difference between the keyword operator is and == is due to
the fact that:
* some people want to compare a custom class and an integer, and if the
custom class' __ methods return the same as the
Feel free to show the docs that contradict this, but this is not
correct. In fact, I think you are talking about Javascript rather than
Python.
On lun, 2014-06-23 at 11:06 -0700, Berlioz Silver wrote:
If someone had read the python docs, they'd have known exactly why
this occurs.
* some people
Dear Pygame experts/enthusiasts around the world,
Having looked at some possible solutions on stackoverflow I optimized the
code to this
#--- play keyboard via computer keyboard ---
if event.type is KEYDOWN:
x = event.unicode
if x in KEYLIST:
v.keyMIDInn =
On dim, 2014-06-22 at 13:13 +0530, diliup gabadamudalige wrote:
Still, if I play the keyboard really fast there are stuck MIDI notes
and stuck animations.
What could be the reason?
First thing you could do, is to check if the events are coming in
correctly. At the top of the event loop, just
Sam Bull wrote:
I don't know if SDL/Pygame is supposed to guarantee these events or
not, it could also be possible that it's just overflowing the keyboard
buffer or something.
Also keep in mind that computer keyboards often don't
handle multiple keys being pressed at once very well,
Also unicode will give you caps if you type shift or caps lock. So if you
hold 'b' then hold shift and let go of 'b' I suspect you'll replicate the
issue. Although it looks like the KEYUP events don't have a unicode so
that may also be it.
It's better to use the key attribute which is independent
SORRY I accidentally sent the message without completion (by hitting the
tab button :) )
code goes like this
def check_chr_key(x):
check if the event.key chr is within printable range
if x 256:
y = chr(x) # get the key that is pressed
else:
y = 0 # dummy value
return y
def get_keys():
Jeffrey Kleykamp wrote:
Although it looks like the KEYUP events don't
have a unicode
That is very true, which means this won't work at all:
if event.type is KEYUP:
x = event.unicode
Also, it's a bad idea to use 'is' to compare ints. It
may appear to work in this case, but it's
thank you Greg. Noted and will correct now.
Thank you Jake B. I commented out the event pump and modified the next
line to this
def get_keys():
#pygame.event.pump()
#mouse buttons left-1, middle-2, right-3
for event in pygame.event.get([KEYDOWN, KEYUP, MOUSEMOTION, MOUSEBUTTONUP]):
so far
Can someone please explain why
if event.type is KEYUP:
is bad and
if event.type == KEYUP:
is correct?
Isn't it the same logic?
On Mon, Jun 23, 2014 at 11:27 AM, diliup gabadamudalige dili...@gmail.com
wrote:
thank you Greg. Noted and will correct now.
Thank you Jake B. I commented out
25 matches
Mail list logo
