Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #52351 > unrolled thread

Re: Python Basic Doubt

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python Basic Doubt Gary Herron <gary.herron@islandtraining.com> - 2013-08-10 20:21 -0700
    Re: Python Basic Doubt Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-11 08:07 +0000

#52351 — Re: Python Basic Doubt

On 08/10/2013 06:00 PM, Chris Angelico wrote:
> On Sun, Aug 11, 2013 at 1:42 AM, Gary Herron
> <gary.herron@islandtraining.com> wrote:
>> On 08/10/2013 03:09 PM, Chris Angelico wrote:
>>> _notpassed = object()
>>> def frob(appendage, device=_notpassed):
>>>       """Use some appendage to frob some device, or None to frob nothing.
>>>       Omit device to frob whatever is currently held in that appendage"""
>>>       if device is _notpassed:
>>>           device = ...  # whatever you need
>>>       if device is not None:
>>>           # frob the device
>>>
>>> But granted, equality comparisons are a LOT more common than identity
>>> comparisons.
>>>
>>> ChrisA
>>
>> Everything you say is true, and even reasonable for those who know what's
>> up.
>>
>> But for each of your examples, using "==" is equivalent to using "is".  Each
>> of
>>      if something == None
>>      if device == _not passed
>>      if device != None
>> would all work as expected.  In none of those cases is "is" actually needed.
> 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.

>
>> Given that, and the implementation dependent oddities, I still believe that
>> it is *highly* misleading to teach a beginner about "is".
>>
>> Here's a challenge:  What is the simplest non-contrived example where an
>> "is" comparison is *required*.  Where substitution of an "==" comparison
>> would cause the program to fail or be significantly less efficient?   (I'm
>> not including the nearly immeasurably small timing difference between
>> v==None and v is None.)
> 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.


>
> ChrisA

[toc] | [next] | [standalone]

#52366

On Sat, 10 Aug 2013 20:21:46 -0700, Gary Herron wrote:

> 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.

"...except for comparing to None, where 99.99% of the time you do 
actually want an identity comparison."

This can lead into a more detailed explanation for why you should choose 
one over the other, or the incurious newbie could take it is something to 
be learned by rote. I have no problem with telling newbies that there is 
a reason for this apparently arbitrary rule, but they don't need to learn 
it *right now* if they don't want.

In any case, the rule can include "When in doubt, use equals". I'm good 
with that :-)


-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web