Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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. The only thing you're saving is a do-nothing trip around the event loop for each event other than the ones you're interested in. Unless you're getting events at an *extremely* high rate, I wouldn't expect that to make a noticeable difference. Also, if you do that, you'll need to somehow clear out all the other event types, otherwise they'll eventually fill up the buffer and you'll start losing events. You *could* do that using event.clear() with a list of all the other event types, but I really doubt whether it's worth the trouble. -- Greg
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 you rely critically on seeing *all* key up events. I don't know why you thought you needed to call event.clear(), but whatever your reason was, it was probably wrong. So may be I had to keep all the unused events for the next time the loop was entered. Is that correct? Exactly correct. -- Greg -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 'is' and '==' will give different results, e.g. 666 == 2 * 333 True 666 is 2 * 333 False You can be misled if you try this experiment with sufficiently small integers, however: 6 is 2 * 3 True This happens because CPython keeps a cache of small integer objects and re-uses them. But that's strictly an implementation detail, and not something you should rely on. The only reliable way to tell whether two ints are equal is to use ==. -- Greg
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 that the queue could eventually fill up with the events you are not interested. But event.get() without an argument takes *all* events from the queue, so this doesn't apply in that case. Also can you explain why if x is True: is not correct and if x == True is correct? Neither of those is correct. You should just be doing if x: ... There might be some very rare cases where comparing something directly with True or False is justified, but then whether to use 'is' or '==' will depend on why you are doing it. -- Greg On Mon, Jun 23, 2014 at 11:34 AM, Greg Ewing greg.ew...@canterbury.ac.nz mailto:greg.ew...@canterbury.ac.nz wrote: 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 you rely critically on seeing *all* key up events. I don't know why you thought you needed to call event.clear(), but whatever your reason was, it was probably wrong. So may be I had to keep all the unused events for the next time the loop was entered. Is that correct? Exactly correct. -- Greg -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 didnt call pygame.event.get() at all. On Jun 23, 2014 2:16 AM, diliup gabadamudalige dili...@gmail.com 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. 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, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 you rely critically on seeing *all* key up events. I don't know why you thought you needed to call event.clear(), but whatever your reason was, it was probably wrong. So may be I had to keep all the unused events for the next time the loop was entered. Is that correct? Exactly correct. -- Greg -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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, 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 didnt call pygame.event.get() at all. On Jun 23, 2014 2:16 AM, diliup gabadamudalige dili...@gmail.com 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. 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, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 you rely critically on seeing *all* key up events. I don't know why you thought you needed to call event.clear(), but whatever your reason was, it was probably wrong. So may be I had to keep all the unused events for the next time the loop was entered. Is that correct? Exactly correct. -- Greg -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ** -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 be possible? On Mon, Jun 23, 2014 at 11:55 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 'is' and '==' will give different results, e.g. 666 == 2 * 333 True 666 is 2 * 333 False You can be misled if you try this experiment with sufficiently small integers, however: 6 is 2 * 3 True This happens because CPython keeps a cache of small integer objects and re-uses them. But that's strictly an implementation detail, and not something you should rely on. The only reliable way to tell whether two ints are equal is to use ==. -- Greg -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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, diliup gabadamudalige dili...@gmail.com wrote: 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 sam.hack...@sent.com wrote: 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 -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ** -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 say this too. I assume if a library is exposing constants to me, that the library uses those constants internally, using direct references. So, the value is always a reference to the actual constant, meaning I can be sure that it is always the constant object itself, and not just an equal value. That is, if: event.type is EVENT returns False, I can be sure it is not that event type, even if they happened to be equal in value. Having flicked through the code, this would appear to be correct. Pygame gets it constants directly from the SDL constants, and the events in SDL directly use the constants and not arbitrary ints. signature.asc Description: This is a digitally signed message part
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
@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) Hope it clears up some things! 2014-06-23 9:37 GMT+02:00 diliup gabadamudalige dili...@gmail.com: 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 sam.hack...@sent.com wrote: 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 -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 speed up the process? If those are the only event types you are interested in across your whole program, then the most efficient and convenient method is to use set_allowed(): http://www.pygame.org/docs/ref/event.html#pygame.event.set_allowed This will stop any other event type going into the queue. This means you don't need to process the other events in your loop, like with your get(typelist) method. But, it also means the queue will never fill up, and you won't have to worry about clearing it. With only the event types you want allowed to enter the queue, you can just use a plain event.get() to get everything, as it will only include the allowed events. signature.asc Description: This is a digitally signed message part
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 integers? What logic is Python using here? As previously mentioned, low integers (0-255 or so, I believe) are interned when Python starts up. This means they will always refer to the same object wherever they are used. But, this is an implementation detail used for optimisation and not something you should rely on in your code. If you created the items separately, you cannot assume they are the same object. They could be the same object, simply depending on how the internal implementation decides to optimise it, but you should never rely on it, unless you have taken the direct reference (a = b), or in the case of strings, used the intern() function to explicitly intern them. As I mentioned before, it should be safe to do this with constants, as you are using the direct reference to the constant itself, and not just creating an integer of the same value. signature.asc Description: This is a digitally signed message part
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 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? As previously mentioned, low integers (0-255 or so, I believe) are interned when Python starts up. This means they will always refer to the same object wherever they are used. But, this is an implementation detail used for optimisation and not something you should rely on in your code. If you created the items separately, you cannot assume they are the same object. They could be the same object, simply depending on how the internal implementation decides to optimise it, but you should never rely on it, unless you have taken the direct reference (a = b), or in the case of strings, used the intern() function to explicitly intern them. As I mentioned before, it should be safe to do this with constants, as you are using the direct reference to the constant itself, and not just creating an integer of the same value. -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 about. Or else you'll lose certain events you do care about when you use clear. Jeffrey On Mon, Jun 23, 2014 at 3:26 AM, diliup gabadamudalige dili...@gmail.com wrote: 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 be possible? On Mon, Jun 23, 2014 at 11:55 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 'is' and '==' will give different results, e.g. 666 == 2 * 333 True 666 is 2 * 333 False You can be misled if you try this experiment with sufficiently small integers, however: 6 is 2 * 3 True This happens because CPython keeps a cache of small integer objects and re-uses them. But that's strictly an implementation detail, and not something you should rely on. The only reliable way to tell whether two ints are equal is to use ==. -- Greg -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ** -- Jeffrey Kleykamp
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 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, diliup gabadamudalige dili...@gmail.com mailto:dili...@gmail.com wrote: 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 sam.hack...@sent.com mailto:sam.hack...@sent.com wrote: 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 -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ** -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 integer, the want a value of true. AND * some people want to know if the number they got IS EXACTLY 3 and won't do wonky stuff when they multiply it. Thus we have 4 operators for equality comparisons: == (eq) === (is) On Mon, Jun 23, 2014 at 8:14 AM, bw stabbingfin...@gmail.com wrote: 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 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, diliup gabadamudalige dili...@gmail.com wrote: 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 sam.hack...@sent.com wrote: 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 -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ** -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 want to know if the number they got IS EXACTLY 3 and won't do wonky stuff when they multiply it. We have just explained it, and this is not the reason. If a value is equal to (==) 3, then it is exactly equal to 3. But, as previously discussed (particularly with numbers above 255), a value of 3 does not need to be the same object (is) as another 3. They can be two identical numbers, stored in the same way, but as separate objects in memory, thus return False when tested with 'is'. This is clearly demonstrated with: a = 2020 a is 2020 # False So, it has absolutely nothing to do with multiplication. Thus we have 4 operators for equality comparisons: == (eq) === (is) That's 2 operators, and one doesn't exist in Python, again, you may be thinking of Javascript. The operators are '==' and 'is'. signature.asc Description: This is a digitally signed message part
[pygame] Re: Pygame not handling keyboard tracking correctly
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_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, 100,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = True if event.type is KEYUP: x = event.unicode if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_off(v.keyMIDInn, 0,1) for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = False Still, if I play the keyboard really fast there are stuck MIDI notes and stuck animations. What could be the reason? Any help is much appreciated. On Sun, Jun 22, 2014 at 12:59 PM, diliup gabadamudalige dili...@gmail.com wrote: Below is my code the indention is wrong here but in the program it is correct if event.type is KEYDOWN: x = check_chr_key(event.key) if x in KEYLIST: if x in KEY_TO_MIDI_NN: # if key in midi note dict v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, 100,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = True if event.type is KEYUP: x = check_chr_key(event.key) if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_off(v.keyMIDInn, 0,1) for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = False If I play the keyboard leisurely this works fine. But If I play the keyboard really fast sometimes the MIDI notes get stuck and so does the Animation ( the stuck MIDI note shows the keyboard note as down) I can't see anything wrong in the code. Is it that Pygame is not scanning the keyboard fast enough? What is the work around to this? -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ** -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 add a print statement 'print(event.key, event.type)', and then check the output to see if you get all the KEYUP events for each key following their KEYDOWN events. If they're all there, and in the right order, then it is a problem with your code, otherwise it might just be missing events. 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. It's also worth noting, though doesn't sound like the problem you're having, that you don't receive keyboard events when the window loses focus, so you could press a button, lose focus, let go of the key, regain focus, and it would never receive the KEYUP event. signature.asc Description: This is a digitally signed message part
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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, which could easily happen if you're trying to play notes quickly. I'd still expect to get a key-up for every key-down, but maybe not. -- Greg
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 of caps lock and shift. Jeffrey On Sun, Jun 22, 2014 at 8:36 PM, Jeffrey Kleykamp jeffrey.kleyk...@gmail.com wrote: 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 == KEYDOWN else False v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, play_number,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = key_select Also your code may run into issues if you change KEYLIST and/or keyboard_full between frames. It may also be that you're losing the screen and pressing getting the keyup event off screen where you may not get it. You can check for the status of keys using the keyboard pygame module independent of events. That'll give you the status of the key right now. Also make sure you're completely using the event buffer. It may get full. If you use event.get(type) then all the other types stay on the list. So use pump to get rid of them. Jeffrey On Sun, Jun 22, 2014 at 3:43 AM, diliup gabadamudalige dili...@gmail.com wrote: 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_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, 100,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = True if event.type is KEYUP: x = event.unicode if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_off(v.keyMIDInn, 0,1) for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = False Still, if I play the keyboard really fast there are stuck MIDI notes and stuck animations. What could be the reason? Any help is much appreciated. On Sun, Jun 22, 2014 at 12:59 PM, diliup gabadamudalige dili...@gmail.com wrote: Below is my code the indention is wrong here but in the program it is correct if event.type is KEYDOWN: x = check_chr_key(event.key) if x in KEYLIST: if x in KEY_TO_MIDI_NN: # if key in midi note dict v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, 100,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = True if event.type is KEYUP: x = check_chr_key(event.key) if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_off(v.keyMIDInn, 0,1) for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = False If I play the keyboard leisurely this works fine. But If I play the keyboard really fast sometimes the MIDI notes get stuck and so does the Animation ( the stuck MIDI note shows the keyboard note as down) I can't see anything wrong in the code. Is it that Pygame is not scanning the keyboard fast enough? What is the work around to this? -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ** -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely,
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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(): pygame.event.pump() #mouse buttons left-1, middle-2, right-3 for event in pygame.event.get(): v.mouse_key = # when the mouse moves off the keyboard v.black_kdown = False if event.type is KEYDOWN: #--- play keyboard via computer keyboard --- x = (event.unicode) if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, 100,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = True if event.type is KEYUP: x = check_chr_key(event.key) if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_off(v.keyMIDInn, 0,1) for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = False above is the related code at the end of the function I had this line pygame.event.clear() before exiting the function somehow when I removed that line the error stopped. I tried hitting the keys in so many different ways but didn't get a single error so far. So may be I had to keep all the unused events for the next time the loop was entered. Is that correct? On Mon, Jun 23, 2014 at 11:09 AM, diliup gabadamudalige dili...@gmail.com wrote: 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_TO_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, 100,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = True if event.type is KEYUP: x = check_chr_key(event.key) if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_off(v.keyMIDInn, 0,1) for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = False v.mousepos = pygame.mouse.get_pos() v.printnotename = [v.mousepos[0] + 12, v.mousepos[1]] On Mon, Jun 23, 2014 at 6:09 AM, Jeffrey Kleykamp jeffrey.kleyk...@gmail.com wrote: 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 of caps lock and shift. Jeffrey On Sun, Jun 22, 2014 at 8:36 PM, Jeffrey Kleykamp jeffrey.kleyk...@gmail.com wrote: 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 == KEYDOWN else False v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, play_number,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = key_select Also your code may run into issues if you change KEYLIST and/or keyboard_full between frames. It may also be that you're losing the screen and pressing getting the keyup event off screen where you may not get it. You can check for the status of keys using the keyboard pygame module independent of events. That'll give you the status of the key right now. Also make sure you're completely using the event buffer. It may get full. If you use event.get(type) then all the other types stay on the list. So use pump to get rid of them. Jeffrey On Sun, Jun 22, 2014 at 3:43 AM, diliup gabadamudalige dili...@gmail.com wrote: 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_MIDI_NN[x] + v.octave player.note_on(v.keyMIDInn, 100,1) # play the note for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = True if event.type is KEYUP: x = event.unicode if x in KEYLIST: v.keyMIDInn = KEY_TO_MIDI_NN[x] + v.octave player.note_off(v.keyMIDInn, 0,1) for key in keyboard_full: if v.keyMIDInn == key.midi_note_no: key.key_select = False Still, if I play the keyboard really fast there are stuck MIDI notes and stuck animations. What could be the reason? Any help is much appreciated. On Sun, Jun 22, 2014 at 12:59 PM, diliup gabadamudalige dili...@gmail.com wrote: Below is my code the indention is wrong here but in the program it
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 only working by accident. You should do this instead: if event.type == KEYUP: ... -- Greg
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 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? On Mon, Jun 23, 2014 at 11:23 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 only working by accident. You should do this instead: if event.type == KEYUP: ... -- Greg -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
Re: [pygame] Re: Pygame not handling keyboard tracking correctly
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 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 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? On Mon, Jun 23, 2014 at 11:23 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: 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 only working by accident. You should do this instead: if event.type == KEYUP: ... -- Greg -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. ** -- Diliup Gabadamudalige http://www.diliupg.com http://soft.diliupg.com/ ** This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. **
