By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,097 Members | 1,580 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,097 IT Pros & Developers. It's quick & easy.

String Identity Test

P: n/a
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
Share this Question
Share on Google+
6 Replies


P: n/a
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

P: n/a
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

P: n/a
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

P: n/a

"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

P: n/a
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

P: n/a
"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.