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
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 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
> 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 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
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
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 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
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, 10
There's no way the python interpreter can get confused so, I guess, the
python programmers though they'd save a little memory that way.
On Mon, Jun 23, 2014 at 3:39 AM, 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
> 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 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.
>
> **
>
>
--
Jeffrey Kleykamp
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 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 > 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
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 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
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
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
> 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 :
>
> 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 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 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
@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 :
> 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 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 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
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
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 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
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 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 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
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 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. **
