comparison with None

[DillonCo]

On Thursday 19 April 2007, Steven Howe wrote:
> > ((int(3) > int(4)) == True) == True
> >
> > Explicit is better than sensible, yes?
> >
> > *wink*
>
> Your example, even with the *wink*, is stupid. The language requires 3
> to be an integer, 4 to be an integer.

Incidentally, the language also requires that None be unique (and the only 
object of type NoneType).  I believe that the point of the 'example' was to 
show that because of the language's guarantees, both are equally pointless.

>
>
> The point I was show is with respect to a returned variable (like from a
> function or method? *wink* *wink*).
> For example, if you expect an open file handle, but get a NoneType
> because you didn't really open a file (having given a bad name or maybe
> didn't have permission to open a file), then it would be best to test
> the type of return object before using it. Then you program could handle
> the error gracefully (*wink* *wink* *wink*).

You don't get "a NoneType", you get None, the unique instance of NoneType.  A 
function cannot return and object of type NoneType without it being None.  
Here's what happens if you try:
>>> from types import ListType
>>> ListType()
[]
>>> from types import NoneType
>>> NoneType()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'NoneType' instances


> As much as I love Python, it's ability to morph an object type can be a
> pain. Testing before using can prevent a program from Error-ing out.

Well, the thing is, that's kind of the point.  In Python, type is supposed to 
be irrelevant.  That's the idea of "duck typing".  If I need to do o.quack(), 
I can do two things to handle the error gracefully:  check if it had the 
quack method ("hasattr"), or catch the exception.

Checking "type(o)==Duck" is wrong almost all the time.  If I subclass Duck 
(to, say a species), it'll likely still be an appropriate object, but then 
type(o)!=Duck.  And what if I want to use a DucklikeGoose?  In that case, 
even "isinstance(o, Duck)" would be False, but it still implements an 
appropriate "quack" method.



Finally, you had said before:
> I love scripting languages ... but sometimes an explicit evaluation that
> one would find in a compiled language is better.
> Which is why I suggested using the explicit type(x) == types.NoneType as
> opposed to
> x is None 

I'll sidestep the issue of Python begin compiled to VM code (think Java)...

How would you do thing in compiled code?
In C, functions that return pointers indicate errors by returning NULL.  
Supposing you had a function that would determine the type of a pointer, 
would you use "type(p)==TYPE_NONE" or "p==NULL"?

In Python, the "is" operator basically compares pointers, so saying "p is q" 
would tanslate to "p==q" in C (supposing p and q are pointers to objects).



At the end of the day, "type(x) == types.NoneType" is going to be true if and 
only if "x is None".  So, whichever way you do it is up to you, though FWIW 
the latter line is:
  Faster: No need for type() call, lookup in types
  Smaller: No need for types module
  Shorter
  Clearer: "is None" shows very clear intent