Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!goblin2!goblin.stu.neva.ru!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
Date: Sat, 10 Aug 2013 21:29:20 -0700
From: Gary Herron <gary.herron@islandtraining.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: python-list@python.org
Subject: Re: Python Basic Doubt
References: <CAL0E0u6wO_UBniWoSpePvhKhPDG_nf4p1rqYYrGwzoHTqp6ZHA@mail.gmail.com> <20130810114040.6ac78fe8@bigbox.christie.dr> <52067FDA.2030908@gmail.com> <5206B527.6080700@islandtraining.com> <CAPTjJmoM=MU2eqa2i_5_RbveXMqScQqu_uFjonwdrZX7Vsc49g@mail.gmail.com> <5206DDED.8030506@islandtraining.com> <CAPTjJmrUGWnQ40iPiJtdKAB8WTbjRaM+bzUmukY6Cb4FvOi2JQ@mail.gmail.com> <5207034A.6070608@islandtraining.com> <CAPTjJmoj5K838vfjuEx9HGDuSb_Uq3=OckqksEk0YsM5Qb4P2w@mail.gmail.com>
In-Reply-To: <CAPTjJmoj5K838vfjuEx9HGDuSb_Uq3=OckqksEk0YsM5Qb4P2w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------050809090303050500030506"
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.464.1376195799.1251.python-list@python.org>
Lines: 207
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:52357

This is a multi-part message in MIME format.
--------------050809090303050500030506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 08/10/2013 08:43 PM, Chris Angelico wrote:
> On Sun, Aug 11, 2013 at 4:21 AM, Gary Herron
> <gary.herron@islandtraining.com> wrote:
>> On 08/10/2013 06:00 PM, Chris Angelico wrote:
>>> Wrong. If you do equality comparisons, it's entirely possible for
>>> something to be passed in that compares equal to the RHS without
>>> actually being it, so "is" is precisely what's wanted. (Plus, why go
>>> through a potentially expensive comparison check when you can simply
>>> check object identity - which could be, for instance, an address
>>> check? But performance is a distant second to correctness here.)
>> You're missing my point.
>>
>> Our knee-jerk reaction to beginners using "is" should be:
>>      Don't do that!  You almost certainly want "==".   Consider "is" an
>> advanced topic.
>>
>> Then you can spend as much time as you want trying to coach them into an
>> understanding of the precise details.  But until they have that
>> understanding, they are well served by a rule-of-thumb that says:
>>      Use "==" not "is" for comparisons.
> No, I'm not missing your point; I'm disagreeing with it. I think that
> 'is' should be taught, that it is every bit as important as '==';
> you're walking down the path of "GOTO considered harmful", of decrying
> some particular language feature because it can be misused.
//
I agree that both "==" and "is" must be taught.  But it's the order in 
which things are introduced which I'm quibbling about.  Something like 
this makes sense (to me):

    Lesson 1: Use "==" for comparisons, save "is" for a more advanced
    lesson.

    Lesson 2: Use "is" for singleton types like "if a is None:" and
    other easily defined circumstances.

    Lesson 3: The whole truth, accompanied by a whole chapter's worth of
    material that describes Python's data model and the difference
    between value versus identity and assignment versus binding ...

A beginner, on his first program or two, can understand 1, and perhaps 
parrot 2 without understanding (or needing to).   But the step from 
there to 3 is huge.  It's folly to dump that on a first-time 
programmer.  (It's probably even folly to dump that on a seasoned 
programmer just starting in Python.  I still remember not understanding 
the explanation for "is" when I first read it.  And it continued to make 
no sense until I had enough experience to understand the difference 
betwen C/C++ assignment to variables and Python's binding of variables.)


>
>>> All it takes is a slightly odd or buggy __eq__ implementation and the
>>> == versions will misbehave. To check if an argument is something, you
>>> use "is", not ==.
>> No, sorry, but any use of the word "is" in an English sentence is way too
>> ambiguous to specify a correct translation into code.   To check "if a
>> calculation of some value is a million", you'd write
>>          value == 1000000
>> not
>>          value is 1000000
>> even though there are plenty of other examples where "is" would be correct.
> Granted, English is a poor litmus test for code. But in this
> particular example, we're talking about immutable types (simple
> integers), where value and identity are practically the same. A Python
> implementation would be perfectly justified in interning *every*
> integer, in which case the 'is' would work perfectly here. The
> distinction between the two is important when the objects are mutable
> (so they have an identity that's distinct from their current values).

Granted.  But please note:  There is *nothing* in that sentence which is 
fit for a beginner programmer.  ... "immutable", "value/identity", 
"interning" ...  In one ear and out the other. :-)

>
> ChrisA


--------------050809090303050500030506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/10/2013 08:43 PM, Chris Angelico
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAPTjJmoj5K838vfjuEx9HGDuSb_Uq3=OckqksEk0YsM5Qb4P2w@mail.gmail.com"
      type="cite">
      <pre wrap="">On Sun, Aug 11, 2013 at 4:21 AM, Gary Herron
<a class="moz-txt-link-rfc2396E" href="mailto:gary.herron@islandtraining.com">&lt;gary.herron@islandtraining.com&gt;</a> wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On 08/10/2013 06:00 PM, Chris Angelico wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Wrong. If you do equality comparisons, it's entirely possible for
something to be passed in that compares equal to the RHS without
actually being it, so "is" is precisely what's wanted. (Plus, why go
through a potentially expensive comparison check when you can simply
check object identity - which could be, for instance, an address
check? But performance is a distant second to correctness here.)
</pre>
        </blockquote>
        <pre wrap="">
You're missing my point.

Our knee-jerk reaction to beginners using "is" should be:
    Don't do that!  You almost certainly want "==".   Consider "is" an
advanced topic.

Then you can spend as much time as you want trying to coach them into an
understanding of the precise details.  But until they have that
understanding, they are well served by a rule-of-thumb that says:
    Use "==" not "is" for comparisons.
</pre>
      </blockquote>
      <pre wrap="">
No, I'm not missing your point; I'm disagreeing with it. I think that
'is' should be taught, that it is every bit as important as '==';
you're walking down the path of "GOTO considered harmful", of decrying
some particular language feature because it can be misused.</pre>
    </blockquote>
    <i>&nbsp;</i><br>
    I agree that both "==" and "is" must be taught.&nbsp; But it's the order
    in which things are introduced which I'm quibbling about.&nbsp; Something
    like this makes sense (to me):<br>
    <blockquote>Lesson 1: Use "==" for comparisons, save "is" for a more
      advanced lesson.<br>
      <br>
      Lesson 2: Use "is" for singleton types like "if a is None:" and
      other easily defined circumstances.<br>
      <br>
      Lesson 3: The whole truth, accompanied by a whole chapter's worth
      of material that describes Python's data model and the difference
      between value versus identity and assignment versus binding ...<br>
    </blockquote>
    A beginner, on his first program or two, can understand 1, and
    perhaps parrot 2 without understanding (or needing to).&nbsp;&nbsp; But the
    step from there to 3 is huge.&nbsp; It's folly to dump that on a
    first-time programmer.&nbsp; (It's probably even folly to dump that on a
    seasoned programmer just starting in Python.&nbsp; I still remember not
    understanding the explanation for "is" when I first read it.&nbsp; And it
    continued to make no sense until I had enough experience to
    understand the difference betwen C/C++ assignment to variables and
    Python's binding of variables.)<br>
    <br>
    <br>
    <blockquote
cite="mid:CAPTjJmoj5K838vfjuEx9HGDuSb_Uq3=OckqksEk0YsM5Qb4P2w@mail.gmail.com"
      type="cite">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">All it takes is a slightly odd or buggy __eq__ implementation and the
== versions will misbehave. To check if an argument is something, you
use "is", not ==.
</pre>
        </blockquote>
        <pre wrap="">
No, sorry, but any use of the word "is" in an English sentence is way too
ambiguous to specify a correct translation into code.   To check "if a
calculation of some value is a million", you'd write
        value == 1000000
not
        value is 1000000
even though there are plenty of other examples where "is" would be correct.
</pre>
      </blockquote>
      <pre wrap="">
Granted, English is a poor litmus test for code. But in this
particular example, we're talking about immutable types (simple
integers), where value and identity are practically the same. A Python
implementation would be perfectly justified in interning *every*
integer, in which case the 'is' would work perfectly here. The
distinction between the two is important when the objects are mutable
(so they have an identity that's distinct from their current values).</pre>
    </blockquote>
    <br>
    Granted.&nbsp; But please note:&nbsp; There is *nothing* in that sentence
    which is fit for a beginner programmer.&nbsp; ... "immutable",
    "value/identity", "interning" ...&nbsp; In one ear and out the other. <span
      class="moz-smiley-s1"><span> :-) </span></span><br>
    <br>
    <blockquote
cite="mid:CAPTjJmoj5K838vfjuEx9HGDuSb_Uq3=OckqksEk0YsM5Qb4P2w@mail.gmail.com"
      type="cite">
      <pre wrap="">

ChrisA
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------050809090303050500030506--