我在试着找出Python的lambda。lambda是那些在现实生活中应该被遗忘的“有趣”语言项之一吗?

我确信有一些边缘情况可能需要它,但是考虑到它的模糊性,它在未来版本中被重新定义的可能性(我基于它的各种定义的假设)以及降低的编码清晰度——应该避免它吗?

这让我想起了C类型的溢出(缓冲区溢出)——指向顶部变量并重载以设置其他字段值。这感觉有点像技术人员的表演,但维护程序员的噩梦。


当前回答

我发现lambda对于执行相同功能的函数列表很有用,但适用于不同的情况。

就像Mozilla的复数规则:

plural_rules = [
    lambda n: 'all',
    lambda n: 'singular' if n == 1 else 'plural',
    lambda n: 'singular' if 0 <= n <= 1 else 'plural',
    ...
]
# Call plural rule #1 with argument 4 to find out which sentence form to use.
plural_rule[1](4) # returns 'plural'

如果你必须为所有这些定义一个函数,到最后你会疯掉的。 另外,像plural_rule_1, plural_rule_2这样的函数名也不太好。当你依赖于变量函数id时,你需要eval()它。

其他回答

两行总结:

闭包:非常有用。学习它们,利用它们,热爱它们。 Python的lambda关键字:不必要,偶尔有用。如果你发现自己在用它做任何复杂的事情,把它放在一边,定义一个真正的函数。

在我看来,lambda的一个好处是,它可以将简单表单的计算推迟到需要值时才进行。让我解释一下。

许多库例程的实现使得它们允许某些参数被调用(lambda是其中之一)。其思想是,实际值只在将要使用它的时候计算(而不是在调用它的时候)。一个(虚构的)例子可能有助于说明这一点。假设你有一个程序,它将记录一个给定的时间戳。您希望例程使用当前时间减去30分钟。你会这么说的

log_timestamp(datetime.datetime.now() - datetime.timedelta(minutes = 30))

现在假设实际函数只在某个事件发生时才被调用,并且您希望仅在该事件发生时计算时间戳。你可以这样做

log_timestamp(lambda : datetime.datetime.now() - datetime.timedelta(minutes = 30))

假设log_timestamp可以像这样处理可调用对象,它将在需要时计算这个值,届时您将获得时间戳。

当然,还有其他方法可以做到这一点(例如使用operator模块),但我希望我已经传达了这一点。

更新:这里有一个更具体的现实世界的例子。

更新2:我认为这是所谓的“坦克”的一个例子。

如上所述,Python中的lambda操作符定义了一个匿名函数,而Python中的函数是闭包。重要的是不要将闭包的概念与操作符lambda混淆,后者对它们来说只是句法上的美沙酮。

当我几年前开始使用Python时,我经常使用lambda,认为它们很酷,还有列表推导式。然而,我编写并维护了一个用Python编写的大型网站,其中有几千个功能点。我从经验中了解到,lambdas可能可以用来创建原型,但除了节省一些键,它不能提供任何内联函数(命名闭包),有时也不能。

基本上这可以归结为几点:

it is easier to read software that is explicitly written using meaningful names. Anonymous closures by definition cannot have a meaningful name, as they have no name. This brevity seems, for some reason, to also infect lambda parameters, hence we often see examples like lambda x: x+1 it is easier to reuse named closures, as they can be referred to by name more than once, when there is a name to refer to them by. it is easier to debug code that is using named closures instead of lambdas, because the name will appear in tracebacks, and around the error.

这就有足够的理由将它们集中起来,并将它们转换为命名闭包。然而,我对匿名闭包还有另外两个不满。

第一个不满是,它们只是又一个不必要的关键字,把语言弄得乱七八糟。

第二个不满是更深层次的,在范式层面上,也就是说,我不喜欢他们提倡一种函数式编程风格,因为这种风格不如消息传递、面向对象或过程式风格灵活,因为lambda微积分不是图灵完备的(幸运的是,在Python中,我们仍然可以在lambda内部突破这种限制)。我觉得lambdas推崇这种风格的原因是:

这里有一个隐式的返回,即它们看起来像“应该”是函数。 它们是另一种更显式、更可读、更可重用和更通用的机制——方法——的状态隐藏机制的替代方案。

我努力编写无lambda的Python,并在看到lambdas时删除lambdas。我认为如果没有lambdas, Python将是一种更好的语言,但这只是我的个人观点。

我可以给你们一个我需要的例子。我正在制作一个图形程序,其中使用右键单击文件并为其分配三个选项之一。事实证明,在Tkinter(我在其中编写的GUI接口程序)中,当有人按下按钮时,它不能被分配给接受参数的命令。所以如果我选择了其中一个选项并希望我选择的结果是:

print 'hi there'

那没什么大不了的。但是如果我需要我的选择有一个特定的细节。例如,如果我选择选项A,它会调用一个函数,该函数接受依赖于选项A、B或C的一些参数,TKinter不支持这一点。拉姆达是唯一的选择,实际上…

I started reading David Mertz's book today 'Text Processing in Python.' While he has a fairly terse description of Lambda's the examples in the first chapter combined with the explanation in Appendix A made them jump off the page for me (finally) and all of a sudden I understood their value. That is not to say his explanation will work for you and I am still at the discovery stage so I will not attempt to add to these responses other than the following: I am new to Python I am new to OOP Lambdas were a struggle for me Now that I read Mertz, I think I get them and I see them as very useful as I think they allow a cleaner approach to programming.

He reproduces the Zen of Python, one line of which is Simple is better than complex. As a non-OOP programmer reading code with lambdas (and until last week list comprehensions) I have thought-This is simple?. I finally realized today that actually these features make the code much more readable, and understandable than the alternative-which is invariably a loop of some sort. I also realized that like financial statements-Python was not designed for the novice user, rather it is designed for the user that wants to get educated. I can't believe how powerful this language is. When it dawned on me (finally) the purpose and value of lambdas I wanted to rip up about 30 programs and start over putting in lambdas where appropriate.