是否有像 Python 2 中那样的内置“应用”函数（如“lambda f: f()”）？

Question

看着this question，我意识到如果要并行运行函数列表，使用multiprocessing 的Pool.map 有点尴尬：

from multiprocessing import Pool

def my_fun1(): return 1
def my_fun2(): return 2
def my_fun3(): return 3

with Pool(3) as p:
   one, two, three = p.map(lambda f: f(), [my_fun1, my_fun2, my_fun3])

我并不是说它完全是神秘的，但我想我希望它有一些传统的名称，即使只是在 functools 或其他东西中，类似于 JavaScript 中的 apply/call（是的，我知道JavaScript 在定义这些函数时没有 lambda，不，我并不是说 JavaScript 是一种示例性编程语言，只是一个示例）。事实上，我绝对认为operator 中应该有类似的东西，但是（除非我的眼睛欺骗了我）它似乎不存在。我读到in the case of the identity function 的解决方案是让人们定义自己的琐碎功能，在这种情况下我更理解它，因为您可能想要一些不同的变体，但这对我来说感觉像是缺失的一点。

编辑：正如 cmets 中所指出的，Python 2 曾经为此目的有一个 apply 函数。

Answer 1

如果你做一行额外的工作，它有点在operator：

>>> def foo():
...     print 'hi'
... 
>>> from operator import methodcaller
>>> call = methodcaller('__call__')
>>> call(foo)
hi

当然，call = lambda f: f() 也只有一行...

Answer 2

首先，我们来看看实际问题。

对于从 2.3 开始的任何 Python，您不仅可以简单地编写无参数 apply，还可以编写完美转发 apply，作为单行符，如 the 2.x docs for apply 中所述：

apply()的使用等价于function(*args, **keywords)

换句话说：

def apply(function, *args, **keywords):
    return function(*args, **keywords)

… 或者，作为内联 lambda：

lambda f, *a, **k: f(*a, **kw)

当然，C 实现要快一些，但这几乎是无关紧要的。¹

如果您要多次使用它，我认为定义函数外线并通过名称重用它可能更清晰，但是 lamdba 版本足够简单和明显（对您来说更是如此no-args 用例），我无法想象有人会抱怨它。

另外，请注意，如果您了解自己在做什么，这实际上比 identity 更简单，而不是更少。使用identity，您应该使用多个参数（或关键字参数）返回什么是模棱两可的，因此您必须决定您想要哪种行为；对于apple，只有一个明显的答案，而且几乎不可能出错。

---

至于历史：

Python 和 JavaScript 一样，最初没有 lambda。在 2.6 之前的版本中很难挖掘可链接的文档，甚至在 2.3 之前也很难找到它们，但我认为 lambda 是在 1.5 中添加的，最终达到了可以在 2.2 左右完美转发的地步。在此之前，文档建议使用apply 进行转发，但在那之后，文档建议使用lambda 代替apply。事实上，apply 已不再被推荐使用。

所以在 2.3 中，该功能已被弃用。²

在导致 3.0 的 Python-3000 讨论期间，Guido 建议除了 可能map 和 filter 之外的所有“函数式编程”函数都是不必要的。^{3 sup> 其他人为 reduce 和 partial 提供了很好的案例。4 但案例的很大一部分是它们实际上并不简单（以完全一般的形式），而且很容易弄错了。 apply 并非如此。此外，人们能够在实际代码库中找到reduce 和partial 的相关用途，但任何人都可以找到的apply 的唯一用途是2.3 之前的旧代码。事实上，这种情况非常罕见，甚至不值得将2to3 工具转换调用为apply。}

删除它的最终理由总结在PEP 3100：

apply()：改用f(*args, **kw) [2]

该脚注链接到 Guido 的一篇名为“Python Regrets”的文章，现在是 404 链接。但是，随附的 PowerPoint 演示文稿是 still available，或者您可以查看他为其编写的演示文稿的 an HTML flipbook。但它真正说的只是同一条线，而 IIRC，唯一进一步的讨论是“我们已经在 2.3 中有效地摆脱了它。”

---

1。在大多数必须应用函数的惯用 Python 代码中，该函数内部的工作非常繁重。当然，在您的情况下，调用函数（腌制参数并将它们通过管道传递）的开销甚至更大。重要的一种情况是当你在做“Haskell 风格的函数式编程”而不是“Lisp 风格的”时——也就是说，只有很少的函数定义，而有很多函数是通过转换函数和组合结果来实现的。但这在 Python 中已经很慢（而且堆栈繁重），所以这不是一件合理的事情。 （平面使用装饰器来应用一个或三个包装器效果很好，但是可能无限的包装器链会影响您的性能。）

2。正式的弃用机制尚不存在，因此它只是移至文档中的“非必要内置函数”部分。但从 2.3 开始，它被追溯认为已弃用，正如您在 2.7 文档中看到的那样。

3。圭多本来连他们都想干掉的；论点是列表推导可以更好地完成相同的工作，正如您在“遗憾”翻书中看到的那样。但是推广itertools.imap 代替map 意味着它可以变得懒惰，就像新的zip 一样，因此比理解更好。我不确定为什么 Guido 不只是对生成器表达式提出相同的论点。

_{4.我不确定 Guido 本人是否曾被 reduce 说服，但核心开发人员作为一个整体是。}