Steven Howe 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.
>
It also requires the reader to have a sense of humor. Where did you
misplace yours? Come on, it was clearly meant to be a light-hearted
poke, don't take life so seriously.
>
> 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*).
>
Here you are actually arguing for the "is" test without realizing it.
Since "is" actually checks for object identity ("do my two operands
occupy the same memory?") it has no need to check the types of its operands.
If there's any possibility that you might have a NoneType (of which, as
I appear to have to keep reminding you, there is precisely ONE instance,
so why not just say "None", since it's the ONLY NoneType object in the
known universe) the correct paradigm is to guard the code with
if f:
...
I am aware that this opens the gates to the hordes who will now pile in
pointing out that this will technique will fail if f is zero (integer,
real or complex) or one of the many other items that evaluates to false
in a Boolean context. I merely point out that none of those things are a
file, and that to allow f to be *either* a file *or* one of those other
things is inviting trouble in a very big way.
However, if the hordes *insist* (as the hordes tend to, especially when
partial to salty snails), the very *most* you need is
if f is None:
...
and anything else is overkill that harms the readability of your
program. It's that poor readability that Steven D'Aprano was making fun
of in his remarks above, which in truth only echoes what I felt like but
refrained from writing when I pointed out the redundancy in the
expression (3 > 4) == True.
> 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.
>
You still don't convince me that there is there is *any* value in
checking the type of an object to determine whether the object is None.
If its type is types.NoneType it *must* be None. If it isn't None then
no harm can be done by an identity comparison with None, since the type
of the operands is irrelevant to "is".
regards
Steve
PS: Revision question: How many objects of type NoneType are there?
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com
--
http://mail.python.org/mailman/listinfo/python-list
