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 peop
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 i
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
That's just a caching issue. Cpython caches small numbers so that a and b
can be the same object. This works because whenever you change the number
you are reassigning the value as opposed to changing a value within the
object.
a = 10
b = 10
a is b # True
a = 100
a is b # False
print(a, b) # 100, 1
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 abou
Thank you very much to all. Now very clear.
May you be well.
On Mon, Jun 23, 2014 at 1:27 PM, Sam Bull 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 both are the same
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 inte
ok. This confusion happens when one ASSUMES that eqality is same, correct?
:)
On Mon, Jun 23, 2014 at 1:15 PM, Fülöp András wrote:
> @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
>
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
@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)
Ho
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
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 PM
ok
look at this!
a = 100
b = 100
a == b
True
a is b
True
a = 1000
b = 1000
a is b
False
a == b
True
what on earth is this? what is this logic?
On Mon, Jun 23, 2014 at 1:03 PM, Sam Bull wrote:
> On lun, 2014-06-23 at 11:45 +0530, diliup gabadamudalige wrote:
> > I called event.clear() cause it
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
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 b
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
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 referr
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 d
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 t
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
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, Gre
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. T
diliup gabadamudalige wrote:
pygame.event.clear()
before exiting the function
somehow when I removed that line the error stopped.
That would definitely be it! You were throwing away any
events that came in between calling event.get() and
reaching the end of your function. Not a good idea when
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
wrote:
> thank you Greg. Noted and will correct now.
>
> Thank you Jake B. I commented out the event pump
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 wor
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 o
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():
Hi all!
my code is like this
def get_keys(): pygame.event.pump() #mouse buttons left-1, middle-2,
right-3 for event in pygame.event.get():
#--- play keyboard via computer keyboard
---
if event.type is KEYUP:
x = (event.unicode)
if x in KEYLIST:
v.keyMIDInn = KEY
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 independen
It may help to have less duplicate code.
if event.type is KEYDOWN or KEYUP:
x = event.unicode
if x in KEYLIST:
play_number = 100 if event.type ==
KEYDOWN else 0
key_select = True if event.type
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,
whi
If I use the keyboard scan routine in several places in the main program
will that help?
On Sun, Jun 22, 2014 at 4:50 PM, Sam Bull wrote:
> 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 anim
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
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 = KEY_TO
33 matches
Mail list logo
