Pragmatics of the standard is() function

[Steven D'Aprano]

On Mon, 28 Nov 2011 11:22:09 -0800, Den wrote:

> With respect, I disagree with advice that the use of a language
> construct should be rare.  All constructs should be used
> *appropriately*.

And if those appropriate conditions are rare, then the use of the 
appropriate construct should also be rare. Since it is rare to need to 
care about identity, use of `is` should be rare too.

This is mostly descriptive statement rather than a prescriptive one: it 
is a fact that use of `is` is much less common than use of ==, and even 
more so if you disregard the obvious case of "x is None". 

I am however being a little prescriptive: if somebody thinks they need to 
care about identity, chances are good -- but not certain -- that they're 
mistaken. In code that gives you the choice between writing `is` and ==, 
it is usually, but not often, a bug to write `is`. The proof of this is 
that in actual, existing code, if you swapped == and `is`, most of the 
code would stop working correctly. 

On the other hand if you actually do need to care about identity, then go 
for it. I'm not saying that caring about identity should be prohibited, 
only that in practice it is uncommon that you will.


> While in general a particular use of a Python construct may be rare, if
> the programmer is involved deeply with that rare use, then it is NOT
> rare to him/her.

Regardless of how common brain surgery might be to a brain surgeon, it is 
rare in general. That's all I'm saying. If you happen to work for a data 
recovery centre, then pulling the disk platter out of a hard disk drive 
might be commonplace to you, nevertheless pulling platters out of disks 
is vanishingly rare: out of tens of thousands of HDDs, perhaps only a few 
dozen will be sent to a recover centre at all.

[...]
> Sorry, you plucked a string of mine.  One does not throw a tool out of
> your tool box because it might be dangerous.  Table saws are incredibly
> dangerous, but in the hands of a skilled operator can be competently and
> safely used to produce beautiful woodwork.  To say *never* use a table
> saw because it's dangerous is silly.

Fortunately, I didn't say "never".

In the case of `is`, one shouldn't avoid using `is` because it is 
dangerous, but merely because it is the wrong thing to use. In the same 
way, the average programmer will rarely need to use the math.sinh and 
math.cosh functions, not because they are bad, evil, or dangerous, but 
because they are used for specialist purposes that most coders would 
never care about. Hell, most coders rarely use the standard trigonometric 
functions sin and cos, let alone the hyperbolic versions! This is not a 
value judgement.

If I, in a misplaced sense of egalitarianism ("Emancipation for maths 
functions! Right on brothers!") decided to use sinh instead of sin 
because they looked and sounded similar, my code would almost certain be 
buggy. Likewise if I decided to use `is` instead of == because in English 
they have similar meanings, my code would probably be buggy too.

Sorry to belabour the point, but we're in violent agreement here <wink>



-- 
Steven