Codecov Report

Merging #18276 into master will decrease coverage by 0.01%.
The diff coverage is 87.5%.

@@            Coverage Diff             @@
##           master   #18276      +/-   ##
==========================================
- Coverage    91.4%   91.38%   -0.02%     
==========================================
  Files         164      164              
  Lines       49878    49878              
==========================================
- Hits        45590    45581       -9     
- Misses       4288     4297       +9

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 69472f9...6402974. Read the comment docs.

Codecov Report

Merging #18276 into master will decrease coverage by 0.01%.
The diff coverage is 87.5%.

@@            Coverage Diff             @@
##           master   #18276      +/-   ##
==========================================
- Coverage    91.4%   91.38%   -0.02%     
==========================================
  Files         164      164              
  Lines       49878    49878              
==========================================
- Hits        45590    45581       -9     
- Misses       4288     4297       +9

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 69472f9...6402974. Read the comment docs.

@mroeschke thanks.

can you add a linting check in ci/lint.sh to search for cases like this?

does this have any perf impact ?

I ran one full asv and two asvs for benchmarks/frame_methods.py and got pretty inconsistent results. I can rerun if needed.

Sure I can include this check in ci/lint.sh. I'll be available to add it later in the week.

thanks

Sure I can include this check in ci/lint.sh. I'll be available to add it later in the week.

would be great

I don't thing you would expect to see any difference in asv. I think this is mainly about code style / redundancy. Certainly given that, apparently (just tried it out, didn't expect this), with small lists it can actually be a bit faster using a list comprehension instead of generator (for bigger ones there is a clear difference though):

In [168]: l = [True, False]*2

In [169]: %timeit any(i for i in l)
511 ns ± 7.38 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [170]: %timeit any([i for i in l])
448 ns ± 11.9 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [171]: l = [True, False]*100

In [172]: %timeit any(i for i in l)
514 ns ± 7.66 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

In [173]: %timeit any([i for i in l])
5.7 µs ± 39.5 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

(and the cases in our code typically are small numbers, eg looping of the axes of a DataFrame (thus 2))