conventions/requirements for 'is' vs '==', 'not vs '!=', etc

[destroooooy]

I'm wondering what is the canonical usage of the keywords 'is' and
'not' when you're writing conditionals and loops. The one I've been
following is completely arbitrary--I use the symbols '==', '!=' for
numerical comparisons and the words 'is', 'not' for everything else.

Thanks in advance!

[Ulrich Eckhardt]

Asun Friere wrote:

Well you have to be careful in case some smartarse comes back with a
class with something like this in it:

def __eq__ (self, other) :
if self is other : return False

That's pretty paranoid. :)
Who said that? (:

Uli

--
Sator Laser GmbH
Geschäftsführ er: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

[Bruno Desthuilliers]

Gabriel Genellina a écrit :

En Mon, 19 May 2008 17:58:48 -0300, br************* ****@gmail.com
<br************ *****@gmail.com escribió:

>On 19 mai, 22:29, Luis Zarrabeitia <[e-mail] te:
(snip)

>>The main
concept here: identity [usually] implies equality,

I really enjoyed the "usually" disclaimer !-)

In some *rare* cases, identity does not imply equality:

Yeps. That's exactly why I enjoyed this disclaimer...

(snip nan example).

[Duncan Booth]

John Salerno <jo******@NOSPA Mgmail.comwrote :

>>>a = 'this is longer'
b = 'this is longer'
a == b

True

>>>a is b

False

>>>>

In the above example, Python has created only one string called
'hello' and both x and y reference it. However, 'this is longer' is
two completely different objects.

That is true when run interactively, but the behaviour changes again if you
run it as a script:

C:\Temp>type t.py
a = 'this is longer'
b = 'this is longer'
print a is b

C:\Temp>t
True

In short, two equal strings may or may not be identical and any code which
makes assumptions based on observed behaviour is broken. If you want to be
able to test identity on strings safely then use the 'intern()' builtin to
get repeatable behaviour.

--
Duncan Booth http://kupuguy.blogspot.com

[castironpi]

On May 20, 5:04*am, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:

John Salerno <johnj...@NOSPA Mgmail.comwrote :

>>a = 'this is longer'
b = 'this is longer'
a == b

True

>>a is b

False

In the above example, Python has created only one string called
'hello' and both x and y reference it. However, 'this is longer' is
two completely different objects.

That is true when run interactively, but the behaviour changes again if you
run it as a script:

C:\Temp>type t.py
a = 'this is longer'
b = 'this is longer'
print a is b

C:\Temp>t
True

In short, two equal strings may or may not be identical and any code which
makes assumptions based on observed behaviour is broken. If you want to be
able to test identity on strings safely then use the 'intern()' builtin to
get repeatable behaviour.

--
Duncan Boothhttp://kupuguy.blogspo t.com

Strictly speaking, identity is a real notion whereas equality is an
ideal (symbolic) notion. There is no such thing as real true equals.
Furthermore, there are no true real symbols. But, as puzzling as that
is:

'abc' == 'abc'
abc is abc

I argue that 'is' should never be used for primitives/literals.

a is 4 #bad
a is b #good
a is 'abc' #bad
a is { None: None } #bad
a== { None: None } #good

Just good thing I don't have check-in priveleges, right? :)

[s0suk3]

On May 20, 9:04 am, castironpi <castiro...@gma il.comwrote:

On May 20, 5:04 am, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:

John Salerno <johnj...@NOSPA Mgmail.comwrote :

>>>a = 'this is longer'
>>>b = 'this is longer'
>>>a == b
True
>>>a is b
False

In the above example, Python has created only one string called
'hello' and both x and y reference it. However, 'this is longer' is
two completely different objects.

That is true when run interactively, but the behaviour changes again if you
run it as a script:

C:\Temp>type t.py
a = 'this is longer'
b = 'this is longer'
print a is b

C:\Temp>t
True

In short, two equal strings may or may not be identical and any code which
makes assumptions based on observed behaviour is broken. If you want to be
able to test identity on strings safely then use the 'intern()' builtin to
get repeatable behaviour.

--
Duncan Boothhttp://kupuguy.blogspo t.com

There is no such thing as real true equals.

That's quite some dark deep philosophy. Fortunately, computers are not
as complicated as real life. I would argue that, programatically ,
there *is* such thing as "real true equals". I would also argue that
that view is most certainly not shared by everyone.

[John Salerno]

"Duncan Booth" <du**********@i nvalid.invalidw rote in message
news:Xn******** *************** **@127.0.0.1...

That is true when run interactively, but the behaviour changes again if
you
run it as a script:

Yeah, I forgot to mention that you shouldn't rely on this behavior. :)

[Terry Reedy]

"Duncan Booth" <du**********@i nvalid.invalidw rote in message
news:Xn******** *************** **@127.0.0.1...
| In short, two equal strings may or may not be identical and any code
which
| makes assumptions based on observed behaviour is broken. If you want to
be
| able to test identity on strings safely then use the 'intern()' builtin
to
| get repeatable behaviour.

Intern() is gone in 3.0

[Rhamphoryncus]

On May 20, 12:09 pm, "Terry Reedy" <tjre...@udel.e duwrote:

Intern() is gone in 3.0

But not gone far:

>>import sys
sys.intern

<built-in function intern>

[castironpi]

On May 20, 11:49*am, [e-mail] m wrote:

On May 20, 9:04 am, castironpi <castiro...@gma il.comwrote:

On May 20, 5:04 am, Duncan Booth <duncan.bo...@i nvalid.invalidw rote:

John Salerno <johnj...@NOSPA Mgmail.comwrote :
>>a = 'this is longer'
>>b = 'this is longer'
>>a == b
True
>>a is b
False

In the above example, Python has created only one string called
'hello' and both x and y reference it. However, 'this is longer' is
two completely different objects.

That is true when run interactively, but the behaviour changes again if you
run it as a script:

C:\Temp>type t.py
a = 'this is longer'
b = 'this is longer'
print a is b

C:\Temp>t
True

In short, two equal strings may or may not be identical and any code which
makes assumptions based on observed behaviour is broken. If you want to be
able to test identity on strings safely then use the 'intern()' builtin to
get repeatable behaviour.

--
Duncan Boothhttp://kupuguy.blogspo t.com

There is no such thing as real true equals.

That's quite some dark deep philosophy. Fortunately, computers are not
as complicated as real life. I would argue that, programatically ,
there *is* such thing as "real true equals". I would also argue that
that view is most certainly not shared by everyone.- Hide quoted text -

- Show quoted text -

Mean as it sounds, bits are pigeonholes: 5+V or 0. As such, computers
are able to simulate numerical identity, but, don't forget, all your
inputs are discretized (pigeonholed).

Symbolic (mathematical) identity (equality) is defined as a reflexive,
symmetric, transitive relation, and partitions its domain into
equivalence classes (membership in which is binary). Symbols are
outside of cause.

Ma: Symbolic identity is a mathematical relation
Mb: Symbols are acausal
m: Matter is causal
C: Symbolic identity is not defined on matter.

Further, conclude computers are symbolic only. Now, what can a hoard
of people do with some symbols?

But, I defer on the practical sense.

[Lie]

On May 20, 10:42*am, John Salerno <johnj...@NOSPA Mgmail.comwrote :

On Mon, 19 May 2008 20:34:22 -0700 (PDT)

notnorweg...@ya hoo.se wrote:

i am confused.

x=5
y=5

x==y -True
x is y -True

shouldnt x is y return False since they shouldnt(dont?) point to the
same place in memory, they just store an equal value?

For some immutable values (such as numbers and strings), Python will have separate variables reference the same object, as an optimization. This doesn't affect anything, since the numbers are immutable anyway and a shared reference won't create any unexpected changes.

It also works with small, but not large, strings:

>x = 'hello'
y = 'hello'
x == y

True

>x is y

True

>a = 'this is longer'
b = 'this is longer'
a == b

True

>a is b

False

In the above example, Python has created only one string called 'hello' and both x and y reference it. However, 'this is longer' is two completely different objects.

But the rule of thumb is: Don't rely on this optimization, it's an
implementation detail.