Hatem added the comment:
Atleast you didnt really challenge my inelegence like greg did. If you
look at my small interpreted session, is returned true the first time.
Why is that. The ticket title may not have been perfect, I was trying
to be sarcastic/funny.
I am asking why are objects
Hatem added the comment:
Really, "is" is not equality but is object equivalence, wow I did not
know that. So why is the first one true MR. This is truly a bug, why
is the first one optimized while the second one isn't. And how come
integers are allways optimized in that sense.
New submission from Hatem :
In [29]: a,b = 1.0,1.0
In [30]: a is b
Out[30]: True
In [31]: a = 1.0
In [32]: b = 1.0
In [33]: a is b
Out[33]: False
# ?!?
--
components: Interpreter Core
messages: 77654
nosy: nassrat
severity: normal
status: open
title: 1 is 1 is allways true while 1.0 is
Hatem <[EMAIL PROTECTED]> added the comment:
On Mon, Dec 1, 2008 at 8:01 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> Antoine Pitrou <[EMAIL PROTECTED]> added the comment:
>
> Le lundi 01 décembre 2008 à 11:15 +, Mark Dickinson a écrit :
>> My initia
Hatem <[EMAIL PROTECTED]> added the comment:
On Mon, Dec 1, 2008 at 7:43 AM, Hatem Nassrat <[EMAIL PROTECTED]> wrote:
> On Mon, Dec 1, 2008 at 7:15 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
>> Well, there are precedents:
>>
>>>>> type(2**3)
>
Hatem <[EMAIL PROTECTED]> added the comment:
On Mon, Dec 1, 2008 at 7:15 AM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> Well, there are precedents:
>
>>>> type(2**3)
>
>>>> type(2**-3)
>
>
> My initial reaction to this was negative, but
New submission from Hatem <[EMAIL PROTECTED]>:
A division which results in int, does not produce int ?!?
Here is the test case.
from __future__ import division
assert(isinstance(2 / 1, int))
--
components: Interpreter Core
messages: 76679
nosy: nassrat
severity: normal
status
