Pragmatics of the standard is() function

Den patentsvnc at gmail.com
Tue Nov 29 12:11:26 EST 2011


On Nov 29, 12:41 am, Steven D'Aprano <steve
+comp.lang.pyt... at pearwood.info> wrote:
> 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

((laugh)) Yes, I believe we are.

D



More information about the Python-list mailing list