String Identity Test

[Thomas Moore]

Hi:

I am confused at string identity test:

Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
About identity, I think a is not b, but "a is b" returns True.
Does that mean equality and identity is the same thing for strings?

 

[Magnus Lycka]

True

About identity, I think a is not b, but "a is b" returns True.
Does that mean equality and identity is the same thing for strings?

Not exactly:
False

It's the same with integers. Small ones are shared, big ones aren't.
Details vary with Python version.

Python sometimes optimizes its memory use by reusing immutable objects.
If you've done 'a="test"', and does 'b="test"', Python sees that it can
save some memory here, so instead of creating a new string object on the
heap (which is what happened when you did 'a="test"'), it makes 'b'
refer to that already existing "test" string object that 'a' refers to.
It's roughly as if you would have written 'b=a' instead.

Of course, it would *never* do this for mutable objects.
'a=[];b=[];a.append(1)' must leave b empty, otherwise Python would be
seriously broken. For immutable objects, this isn't a problem though.
Once created, the 'test' string object will always be the same until
it's destroyed by garbage collection etc.

Were you planning to write code that relied on id(x) being different
for different but identical strings x or do you just try to understand
what's going on?

 

[Duncan Booth]

I am confused at string identity test:

Does that mean equality and identity is the same thing for strings?

Definitely not. What is actually happening is that certain string literals
get folded together at compile time to refer to the same string constant,
but you should never depend on this happening.

If 'a!=b' then it will also be the case that 'a is not b', but if 'a==b'
then there are no guarantees; any observed behaviour is simply an accident
of the implementation and could change:

Testing for identity is only useful in very rare situations, most of the
time you are better just to forget there is such a test.

 

[Roy Smith]

If 'a!=b' then it will also be the case that 'a is not b'

That's true for strings, and (as far as I know), all pre-defined
types, but it's certainly possible to define a class which violates
that.

class isButNotEqual:
def __ne__ (self, other):
return True

a = isButNotEqual()
b = a
print "a != b:", a != b
print "a is not b:", a is not b


framelay$ ./eq.py
a != b: True
a is not b: False

On the other hand, I can't imagine any reason why you would want to
define such a class, other than as a demonstration (or part of an
obfuscated Python contest).

 

[Richard Brodie]

On the other hand, I can't imagine any reason why you would want to
define such a class,

PEP 754?

 

[Thomas Moore]

Hi:

Were you planning to write code that relied on id(x) being different
for different but identical strings x or do you just try to understand
what's going on?

Just try to understand what's going on.....

Thanks All.

 

[Tim Roberts]

PEP 754?

My congratulations on a very subtle and somewhat multicultural joke...