Differences between functools.partial and a similar lambda?

Question

In Python, suppose I have a function f that I want to pass around with some secondary arguments (assume for simplicity that it's just the first argument that remains variable).

What are the differences between doing it these two ways (if any)?

# Assume secondary_args and secondary_kwargs have been defined

import functools

g1 = functools.partial(f, *secondary_args, **secondary_kwargs)
g2 = lambda x: f(x, *secondary_args, **secondary_kwargs)

In the doc page for partial, for example, there is this quote:

partial objects defined in classes behave like static methods and do not transform into bound methods during instance attribute look-up.

Will the lambda-method suffer from this if used to make a class method from arguments supplied to the class (either in the constructor or through a function later on)?

Answer 1

1. A lambda function has the same type as a standard function, so it will behave like an instance method.

2. The partial object in your example can be called like this:

   g1(x, y, z)
   

   leading to this call (not valid Python syntax, but you get the idea):

   f(*secondary_args, x, y, z, **secondary_kwargs)
   

   The lambda only accepts a single argument and uses a different argument order. (Of course both of these differences can be overcome – I'm just answering what the differences between the two versions you gave are.)

3. Execution of the partial object is slightly faster than execution of the equivalent lambda.

Answer 2

Summary

The practical differences between lambda and functools.partial in the common use cases seems to be

• functools.partial needs an import, lambda does not.
• The function definition for functions created with functools.partial is visible just by printing the created function. The functions created with lambda should be inspected with inspect.getsource().

These were found to be practically identical for lambda and functools.partial

• Speed
• Tracebacks

Speed (lambda vs functools.partial)

I think that tests and real data speaks louder than just guesses about which one is faster than the another.

Looks like that there is no statistical proof for speed difference between lambda and functools.partial. I ran different tests with different amount of repetitions, getting slightly different results each time; any of the three approaches could be the fastest. The speeds were identical with 95% (2 sigma) confidence. Here are some numerical results*

# When functions are defined beforehand
In [1]: timeit -n 1000 -r 1000 f_partial(data)
23.6 µs ± 2.92 µs per loop (mean ± std. dev. of 1000 runs, 1000 loops each)

In [2]: timeit -n 1000 -r 1000 f_lambda(data)
22.6 µs ± 2.6 µs per loop (mean ± std. dev. of 1000 runs, 1000 loops each)

# When function is defined each time again
In [3]: timeit -n 1000 -r 1000 (lambda x: trim_mean(x, 0.1))(data)
22.6 µs ± 1.98 µs per loop (mean ± std. dev. of 1000 runs, 1000 loops each)

In [4]: timeit -n 1000 -r 1000 f_lambda = lambda x: trim_mean(x, 0.1); f_lambda(data)
23.7 µs ± 3.89 µs per loop (mean ± std. dev. of 1000 runs, 1000 loops each)

In [5]: timeit -n 1000 -r 1000 f_partial = partial(trim_mean, proportiontocut=0.1); f_partial(data)
24 µs ± 3.38 µs per loop (mean ± std. dev. of 1000 runs, 1000 loops each)

Tracebacks

I also tried running the f_lambda and f_partial using list with string element inserted, and the tracebacks were equal (except for the very first entry, of course). So there is no difference there.

Inspecting the source code

• The function definition for functions created with functools.partial is visible just by printing the created function. The functions created with lambda should be inspected with inspect.getsource().

# Can be inspected with just printing the function
In [1]: f_partial
Out[1]: functools.partial(<function trim_mean at 0x000001463262D0D0>, proportiontocut=0.1)

In [2]: print(f_partial)
functools.partial(<function trim_mean at 0x000001463262D0D0>, proportiontocut=0.1)

# Lambda functions do not show the source directly
In [3]: f_lambda
Out[3]: <function __main__.<lambda>(x)>

# But you can use inspect.getsource()
In [4]: inspect.getsource(f_lambda)
Out[4]: 'f_lambda = lambda x: trim_mean(x, 0.1)\n'

# This throws a ValueError, though.
In [5]: inspect.getsource(f_partial)

Appendix

* Setup used in the tests

from functools import partial
from scipy.stats import trim_mean
import numpy as np
data = np.hstack((np.random.random(1000), np.random.random(50)*25000))

f_lambda = lambda x: trim_mean(x, 0.1)
f_partial = partial(trim_mean, proportiontocut=0.1)

The tests were performed on Python 3.7.3 64-bit (Windows 10).

Answer 3

The most important point here is missed - lambda have links to input vars, but partition make a copy of args during creation:

>>> for k,v in {"1": "2", "3": "4"}.items():
...     funcs.append(lambda: print(f'{k}: {v}'))
...
>>> print(funcs)
[<function <lambda> at 0x106db71c0>, <function <lambda> at 0x10747a3b0>]
>>> for f in funcs:
...     f()
...
3: 4  # result are indentical
3: 4

>>> import functools
>>> funcs = []
>>> for k,v in {"1": "2", "3": "4"}.items():
...     funcs.append(functools.partial(print, f'{k}: {v}'))
...
>>> print(funcs)
[functools.partial(<built-in function print>, '1: 2'), functools.partial(<built-in function print>, '3: 4')]
>>>
>>> for f in funcs:
...     f()
...
1: 2  # result differs
3: 4

Answer 4

partials are not only about 20% faster than equivalent lambdas as already said but they keep a direct ref to they function the relate to. While in lambdas that function is 'buried' within the function body.

=> If you need to only solve the problem of deferring evaluation of one function until all args are known then use partials. You'll have way better introspection methods compared to bury the calls into anonymous functions, i.e. lambdas.

Answer 5

I believe that the class method thing only applies to functions assigned during class definition. Functions assigned later are not treated specially.

Other than that, I'd personally favor lambdas since they're more common and hence make the code easier to understand.

class Foo(object):
    def __init__(self, base):
        self.int = lambda x:int(x, base)

print Foo(4).int('11')

Answer 6

Yes, lambda will "suffer" from this. partial doesn't have this problem because it is an object with the call operator overloaded, rather than a real function.

But using a lambda like this in a class definition is just misuse.