You're reading the pure-python version of operator.py. You get the builtin versions of the same functions - not the python functions when you use it - see the import of _operator further down the file.

Also verify the type info on the object here:

  In [1]: import operator
  In [5]: operator.add??
  Signature: operator.add(a, b, /)
  Docstring: Same as a + b.
  Type:      builtin_function_or_method

I mean, it's the reason the benchmark is slower, because the benchmark is comparing doing 2 things with only doing one of those things -- this is virtually tautological.

So I agree that it is why it's slower, but I also agree that it's a mistake. This is the "hard part" about synthetic benchmarks. This one is measuring something people rarely do: creating an anonymous function and calling it in a tight loop.

It's extremely unlikely you're ever going to run into a situation where creating this lambda is in a hot path, and if you do the thing you did wrong is very unlikely to be whether you used a standard library function or one you defined yourself. It's that you have a loop where you did almost nothing but create a lambda every iteration instead of, say, passing it to a map/fold function or whatever.

'operator' actually maps to C implementations if possible; you're still calling Python functions, but the implementations in 'operator' should be a bit faster than defining your own in pure Python (or the pure Python implementations that get used if the _operator C module is not available for some reason): https://github.com/python/cpython/blob/3.9/Modules/_operator...

A typical use case for lambdas is passing them as arguments to other functions, which implicitly assigns the lambda to some local variable. Using "def" instead would be unlikely to be cleaner.

Maybe you still want to know how long it takes to create a lambda or import from operator, but if such a function is being called more than a few times (and if not, why are we concerned about performance?), execution time will dominate other factors.