Difference between 'is' and '=='
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?
More information about the Python-list