Removing None objects from a sequence

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Fri Dec 12 23:55:20 CET 2008


On Fri, 12 Dec 2008 21:18:36 +0000, Lie Ryan wrote:

> On Fri, 12 Dec 2008 11:50:38 -0500, Steve Holden wrote:
> 
>> Kirk Strauser wrote:
>>> At 2008-12-12T15:51:15Z, Marco Mariani <marco at sferacarta.com> writes:
>>> 
>>>> Filip Gruszczyński wrote:
>>>>
>>>>> I am not doing it, because I need it. I can as well use "if not elem
>>>>> is None",
>>> 
>>>> I suggest "if elem is not None", which is not quite the same.
>>> 
>>> So what's the difference exactly?  "foo is not None" is actually
>>> surprising to me, since "not None" is True.  "0 is True" is False, but
>>> "0 is not None" is True.  Why is that?
>> 
>> "is not" is an operator, so the parse is
>> 
>> foo (is not) None
>> 
>> not
>> 
>> foo is (not None)
>> 
>> 
> Personally, I'd prefer VB's version:
> foo IsNot bar
> 
> or in pseudo-python
> foo isnot bar
> 
> since that would make it less ambiguous.

"a is not b" is no more ambiguous than "1+2*3". True, there's ambiguity 
if you are ignorant of the precedence rules, but that's no worse than 
saying that "+" is ambiguous if you don't know what "+" means.

"What's this 'is' operator??? It's ambiguous, it could mean ANYTHING!!! 
Panic panic panic panic!!!"

*wink*

You're allowed to assume the normal conventions, and (lucky for me!) 
despite being Dutch Guido choose to assume the normal English convention 
that "a is not b" means the same as "not (a is b)" rather than "a is (not 
b)". That's probably because the use-cases for the second would be rather 
rare.

So given the normal precedence rules of Python, there is no ambiguity. 
True, you have to learn the rules, but that's no hardship.



-- 
Steven




More information about the Python-list mailing list