How do I check all variables returned buy the functions exists

[Steve D'Aprano]

On Wed, 20 Sep 2017 06:04 pm, Bill wrote:

> Robin Becker wrote:
>> On 16/09/2017 01:58, Steve D'Aprano wrote:
>> ........
>>>
>>> If you want to test for None specifically:
>>>
>>> if any(v is None for v in values):
>>>      print "at least one value was None"
>>>
>> .......
>>
>> for some reason that seems slow on my machine when compared with
>>
>> if None in values:
>>    .....


I'm not sure whether to be surprised or not.

The first one only checks for identity, which should be really fast, while the
`is` operator tests for equality too, which may slow things down a touch. So
that suggests that any(...) ought to be faster.

But any(...) is iterating over a generator expression, which has overhead,
whereas `None in values` may have less overhead.

On balance, I expected any(...) to be a smidgen faster, but I guess I'm not that
surprised if it went the other way.

Ah... I see that Robin is using especially small tuples, of only three items.
Yes, I can see why the overhead of the generator expression would slow that
down. But try it with a list of a thousand values... 

... and the `is` operator is still faster. Today I learned something.

[steve at ando ~]$ python3.5 -m timeit -s "values=list(range(1000))+[None]" 
 "any(x is None for x in values)"
1000 loops, best of 3: 191 usec per loop

[steve at ando ~]$ python3.5 -m timeit -s "values=list(range(1000))+[None]"
 "None in values"
10000 loops, best of 3: 60.1 usec per loop


> This does not seem particularly surprising.  "None in values" is known
> as soon as None is found.

That's how any() works too. It returns as soon as it finds a true result.


> In "any(v is None for v in values)",  "any" probably isn't called until
> its argument is (fully) known.

No, its a generator expression, so it provides the values one at a time, as
needed.


> Of course the results would depend on 
> the implementation.  It would be interesting to compare the results if
> you used the optimize option (it's either -o or -O).

I wouldn't expect that to make any difference. Currently Python's optimization
levels are pretty weak sauce:

-O disables any assert statements;

-OO disables asserts, and removes docstrings.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.