Difference between 'is' and '=='

Joel Hedlund joel.hedlund at gmail.com
Wed Mar 29 11:08:38 CEST 2006

> There's no requirement that the socket module or
> anything else return values using the same object that the
> socket.AF_UNIX constant uses.

Ouch. That's certainly an eyeopener.

For me, this means several things, and I'd really like to hear people's 
thoughts about them.

It basically boils down to "don't ever use 'is' unless pushed into a corner, 
and nevermind what PEP8 says about it".

So here we go... *takes deep breath*

Identity checks can only be done safely to compare a variable to a defined 
builtin singleton such as None. Since this is only marginally faster than a 
value equality comparison, there is little practical reason for doing so. 
(Except for the sake of following PEP8, more of that below).

You cannot expect to ever have identity between a value returned by a 
function/method and a CONSTANT defined in the same package/module, if you do 
not have comlete control over that module. Therefore, such identity checks 
should always be given a value equality fallback. In most cases the identity 
check will not be significantly faster than a value equality check, so for the 
sake of readability it's generally a good idea to skip the identity check and 
just do a value equality check directly. (Personally, I don't think it's good 
style to define constants and not be strict about how you use them, but that's 
on a side note and not very relevant to this discussion)

It may be a good idea to use identity checks for variables vs CONSTANTs defined 
in the same module/package, if it's Your module/package and you have complete 
control over it. Felipe Almeida Lessa provided a good argument for this earlier 
in this thread:

> Here I knew 128 == MSG_EOR, but what if that was a
> coincidence of some other function I created? I would *never* catch that
> bug as the function that tests for MSG_EOR expects any integer. By
> testing with "is" you test for *that* integer, the one defined on your
> module and that shouldn't go out of it anyway.

However it may be a bad idea to do so, since it may lure you into a false sense 
of security, so you may start to unintentionally misuse 'is' in an unsafe manner.

So the only motivated use of 'is' would then be the one shown in my first 
example with the massive_computations() function: as a shortcut past costly 
value equality computations where the result is known, and with an added value 
equality fallback for safety. Preferably, the use of identity should then also 
be motivated in a nearby comment.

My conlusion is then that using 'is' is a bad habit and leads to less readable 
code. You should never use it, unless it leads to a *measurable* gain in 
performance, in which it should also be given a value equality fallback and a 
comment. And lastly, PEP8 should be changed to reflect this.

Wow... that got a bit long and I applaud you for getting this far! :-) Thanks 
for taking the time to read it.

So what are your thoughts about this, then?

/Joel Hedlund

More information about the Python-list mailing list