468,294 Members | 1,812 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,294 developers. It's quick & easy.

String Identity Test

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.
a="test"
b="test"
a is b 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?
Nov 1 '05 #1
6 1432
Thomas Moore wrote:
I am confused at string identity test:
<snip>
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:
a="test 1"
b="test 1"
a is b False a="test"
b="test"
a is b True


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.

Nov 1 '05 #2
Thomas Moore wrote:
a="test"
b="test"
a is b
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:
a="this is also a string"
b="this is also a string"
a is b

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?
Nov 1 '05 #3
Duncan Booth <du**********@suttoncourtenay.org.uk> wrote:
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
frame:play$ ./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).
Nov 1 '05 #4

"Roy Smith" <ro*@panix.com> wrote in message news:dk**********@panix2.panix.com...
On the other hand, I can't imagine any reason why you would want to
define such a class,


PEP 754?
Nov 1 '05 #5
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.

Nov 2 '05 #6
"Richard Brodie" <R.******@rl.ac.uk> wrote:

"Roy Smith" <ro*@panix.com> wrote in message news:dk**********@panix2.panix.com...
On the other hand, I can't imagine any reason why you would want to
define such a class,


PEP 754?


My congratulations on a very subtle and somewhat multicultural joke...
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Nov 3 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by grzes | last post: by
26 posts views Thread by Neville Lang | last post: by
reply views Thread by Frank Swarbrick | last post: by
reply views Thread by Teichintx | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.