Python Basic Doubt

[Gary Herron]

On 08/10/2013 08:43 PM, Chris Angelico wrote:
> On Sun, Aug 11, 2013 at 4:21 AM, Gary Herron
> <gary.herron at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20130810/1e571ba5/attachment.html>