comparison with None

[Chris Mellon]

On 4/19/07, Steven Howe <howe.steven at gmail.com> wrote:
>
>  Steven D'Aprano wrote:
>  On Thu, 19 Apr 2007 08:18:30 -0400, Steve Holden wrote:
>
>
>
>
>  Which is why I suggested using the explicit type(x) == types.NoneType as
> opposed to
> x is None
>
>
>
>  This seems to go entirely against the spirit of the language. It's about
> as sensible as writing
>
>  (3 > 4) == True
>
>
> Please! For extra certainty, you should write that as:
>
> ((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.
>
>
>  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),

This won't happen, because an exception will be thrown instead. But if
it *did*, you'd test with "is None", not by type comparison.

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

This is contrary to the vast majority of Python philosophy. Embracing
rather than fighting it will result in a much more pleasant Python
experience.

>  Steven Howe
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>