Partial application is cool. What functionality does functools.partial offer that you can't get through lambdas?
>>> sum = lambda x, y : x + y
>>> sum(1, 2)
3
>>> incr = lambda y : sum(1, y)
>>> incr(2)
3
>>> def sum2(x, y):
return x + y
>>> incr2 = functools.partial(sum2, 1)
>>> incr2(4)
5
Is functools somehow more efficient, or readable?
I understand the intent quickest in the third example.
When I parse lambdas, I'm expecting more complexity/oddity than offered by the standard library directly.
Also, you'll notice that the third example is the only one which doesn't depend on the full signature of sum2; thus making it slightly more loosely coupled.
Well, here's an example that shows a difference:
In [132]: sum = lambda x, y: x + y
In [133]: n = 5
In [134]: incr = lambda y: sum(n, y)
In [135]: incr2 = partial(sum, n)
In [136]: print incr(3), incr2(3)
8 8
In [137]: n = 9
In [138]: print incr(3), incr2(3)
12 8
These posts by Ivan Moore expand on the "limitations of lambda" and closures in python:
What functionality does functools.partial offer that you can't get through lambdas?
Not much in terms of extra functionality (but, see later) -- and, readability is in the eye of the beholder. Most people who are familiar with functional programming languages (those in the Lisp/Scheme families in particular) appear to like lambda just fine -- I say "most", definitely not all, because Guido and I definitely are among those "familiar with" (etc) yet think of lambda as an eyesore anomaly in Python... he was repentant of ever having accepted it into Python and planned to remove it in Python 3, as one of "Python's glitches", and I fully supported him in that. (I love lambda in Scheme... but its limitations in Python, and the weird way it just doesn't fit in with the rest of the language, make my skin crawl).
Not so, however, for the hordes of lambda lovers -- who staged one of the closest things to a rebellion ever seen in Python's history, until Guido backtracked and decided to leave lambda in. Several possible additions to functools (to make functions returning constants, identity, etc) didn't happen (to avoid explicitly duplicating more of lambda's functionality), though partial did of course remain (it's no total duplication, nor is it an eyesore).
Remember that lambda's body is limited to be an expression, so it's got limitations. For example...:
>>> import functools
>>> f = functools.partial(int, base=2)
>>> f.args
()
>>> f.func
<type 'int'>
>>> f.keywords
{'base': 2}
>>>
functools.partial's returned function is decorated with attributes useful for introspection -- the function it's wrapping, and what positional and named arguments it fixes therein. Further, the named arguments can be overridden right back (the "fixing" is rather, in a sense, the setting of defaults):
>>> f('23', base=10)
23
So, as you see, it's definely not as simplistic as lambda s: int(s, base=2)!-)
Yes, you could contort your lambda to give you some of this -- e.g., for the keyword-overriding,
>>> f = lambda s, **k: int(s, **dict({'base', 2}, **k))
but I dearly hope that even the most ardent lambda-lover doesn't consider this horror more readable than the partial call!-). And, the "attribute setting" part is even harder, because of the "body's a single expression" limitation of Python's lambda (plus the fact that assignment can never be part of a Python expression)... you end up "faking assignments within an expression" by stretching list comprehension well beyond its design limits...:
>>> f = [f for f in (lambda f: int(s, base=2),)
if setattr(f, 'keywords', {'base': 2}) is None][0]
Now combine the named-arguments overridability, plus the setting of three attributes, into a single expression, and tell me just how readable that is going to be...!-)