Difference between 'is' and '=='

Adam DePrince adam.deprince at gmail.com
Mon Apr 3 10:11:44 EDT 2006


On Mon, 2006-03-27 at 17:17 -0500, Terry Reedy wrote:
> "Clemens Hepper" <ethrandil at gmx.net> wrote in message 
> news:e08qgg$nt$1 at news2.open-news-network.org...
> 
> > It's strange: python seem to cache constants from 0 to 99:
> 
> The Python specification allows but does not require such behind-the-scenes 
> implementation optimization hacks.  As released, CPython 2.4 caches -5 to 
> 99, I believe.  In 2.5, the upper limit was increased to 256.  The limits 
> are in a pair of #define statements in the int object source file.  Anyone 
> who compiles from source can adjust as desired (though the corresponding 
> test will fail unless also adjusted ;-).
> 
> I think the visibility of this implementation detail from Python code is an 
> example of a leaky abstraction.  For more, see
> http://www.joelonsoftware.com/articles/LeakyAbstractions.html

I disagree wholeheartedly with this.  == and is are two very different
operators that have very different meaning.  It just happens that the
logical operation 

 (a is b ) -> (a == b )

is always True.  

There is no abstraction going on here; a==b is not an abstract version
of a is b.  They are different operations.

a == b tests if the values of objects at a and b are equal.  a and b
point be the same darn object, or they might be different objects, but
the question we are asking is if they have the same value.  

The is operator is different, you use it if you are interested in
introspecting the language.  

Some people have noticed that  1 + 1 is 2 will return True and  1 + 100
is 101 returns False.   This isn't a "leaky abstraction" unless you
wrongly consider is to be an analogy for ==.

Python has certain optimizations ... small strings and numbers are
"interned," that is canonical copies are maintained and efforts to
create fresh objects result in the old cached copies being returned,
albeit with higher reference counts.  This saves memory and time; time
because for any intern-able objects the truth of the first test is a
realistic possibility.

if a is b:
	return True
if hash( a ) != hash( b )
	return False
... Now do proper equality testing. ... 

As for "joelonsoftware's" leaky abstraction article, I respectfully
disagree.  His leaky abstractions are merely inappropriate analogies.
TCP is perfectly reliable with respect to its definition of
reliability.  

As for wipers abstracting away the rain ...

Well over a decade ago I recall walking to lunch with my supervisor, a
truly masterful C programmer.  We worked in Manhattan, a land where two
way streets are the exception.  When crossing each street he would look
the wrong way, look the correct way and then stare the wrong way again.
Upon noticing my inquisitorial expression, he answered "A good
programmer always looks both ways when crossing a one way street."   

I'm uncertain that a quip about abstracting away the rain would have
prompted the same adjective "masterful" now 10+ years in the future.

- Adam DePrince





More information about the Python-list mailing list