Codecov Report

Merging #14284 into master will decrease coverage by <.01%.
The diff coverage is 86.53%.

@@            Coverage Diff             @@
##           master   #14284      +/-   ##
==========================================
- Coverage   82.75%   82.75%   -0.01%     
==========================================
  Files        1840     1840              
  Lines      560791   560780      -11     
  Branches    41431    41431              
==========================================
- Hits       464110   464099      -11     
- Misses      87598    87602       +4     
+ Partials     9083     9079       -4

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 770847a...fc44c0e. Read the comment docs.

Is partial_vectorcall_no_args useful? It kicks in only if no arguments (positional nor keyword) are added at all. Are such no-op partial objects worth optimizing?

Are such no-op partial objects worth optimizing?

To be honest, I have no idea. I just noticed that this could be optimized, so I did it. The behaviour of partial(func) would be just like staticmethod(func) but callable itself.

Do you want me to remove that special case?

To be honest, I have no idea. I just notices that this could be optimized, so I did it.

That sounds like premature optimization.
I wonder how much this PR itself helps; did you run any benchmarks?

The behaviour of partial(func) would be just like staticmethod(func) but callable itself.

If that is an actual use case for that, just make staticmethod callable. AFAIK, in the discussions around that ⁽⁰⁾ ⁽¹⁾, the only arguments against were not enough actual use cases.
We shouldn't optimize for people repurposing partial for this.

Do you want me to remove that special case?

Yes, unless there is a need for the complication.

I tried 3 simple micro-benchmarks (without PGO):

1. f = partial(len) and then benchmarking f(())
   before: Mean +- std dev: 70.3 ns +- 0.2 ns
   after: Mean +- std dev: 47.3 ns +- 0.1 ns
2. f = partial(len, []) and then benchmarking f()
   before: Mean +- std dev: 50.2 ns +- 0.2 ns
   after: Mean +- std dev: 36.1 ns +- 0.3 ns
3. f = partial(list.count, []) and then benchmarking f(0)
   before: Mean +- std dev: 84.4 ns +- 1.3 ns
   after: Mean +- std dev: 47.9 ns +- 2.2 ns

So there is a clear performance improvement in all cases.

Failed Travis CI build is due to OSError: [Errno 113] No route to host clearly not caused by this PR.

Looks good! Thank you!

@jdemeyer: Status check is done, and it's a success ✅ .