首先恭喜你算出了。在我看来，这是一个非常强大的构念。如今函数式编程语言的发展趋势无疑表明，在不久的将来，它既不应该被避免，也不会被重新定义。

你只需要换个角度思考。我相信你很快就会爱上它的。但是如果你只和python打交道要小心。因为lambda不是一个真正的闭包，它以某种方式“坏了”:python的lambda坏了

函数这是一种非官僚化的创建函数的方法。

就是这样。例如，假设你有一个主要函数，需要对值平方。我们来看看传统的方法和的方法

传统的方法:

def main():
...
...
y = square(some_number)
...
return something

def square(x):
    return x**2

方式:

def main():
...
square = lambda x: x**2
y = square(some_number)
return something

看到区别了吗?

Lambda函数非常适合用于列表，比如列表推导式或映射。事实上，列表理解是一种使用lambda来表达自己的“python”方式。例:

>>>a = [1,2,3,4]
>>>[x**2 for x in a]
[1,4,9,16]

让我们看看每个语法元素的含义:

[]:“给我一个清单” X **2:“使用这个新诞生的函数” 对于a中的x: "into each element in a"

很方便吧?创建这样的函数。让我们用lambda重写它:

>>> square = lambda x: x**2
>>> [square(s) for x in a]
[1,4,9,16]

现在让我们使用map，这是同样的东西，但更语言中立。Maps有两个参数:

(i)一个功能

(ii)可迭代对象

给你一个列表，其中每个元素它是应用于可迭代对象的每个元素的函数。

使用map，我们会得到:

>>> a = [1,2,3,4]
>>> squared_list = map(lambda x: x**2, a)

如果你掌握了lambdas和映射，你将拥有以简洁的方式操作数据的强大能力。Lambda函数既不晦涩，也不影响代码的清晰性。不要把难的东西和新东西混为一谈。一旦你开始使用它们，你就会发现非常清楚。

我怀疑lambda不会消失。 请参阅Guido关于最终放弃尝试删除它的帖子。也请参阅冲突概要。

你可以看看这篇文章，了解更多Python函数特性背后的交易历史: http://python-history.blogspot.com/2009/04/origins-of-pythons-functional-features.html

奇怪的是，最初引入lambda和其他函数特性的map、filter和reduce函数在很大程度上已经被列表推导式和生成器表达式所取代。事实上，在Python 3.0中，reduce函数已从内置函数列表中删除。(但是，没有必要投诉lambda、map或filter的删除:它们被保留了。: -)

我个人的意见是:就清晰度而言，lambda值不了多少。通常有一个更清晰的不包含的解。

如上所述，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将是一种更好的语言，但这只是我的个人观点。

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.

我刚开始学习Python，然后一头栽进Lambda——这花了我一段时间才弄明白。

请注意，这不是对任何事情的谴责。每个人都有不容易得到的东西。

lambda是那些在现实生活中应该被遗忘的“有趣”语言项目之一吗?

No.

我相信有一些边缘情况可能需要它，但考虑到它的模糊性，

它并不晦涩。在我过去工作过的两个团队中，每个人都一直在使用这个功能。

它在未来版本中被重新定义的可能性(我基于它的各种定义的假设)

除了几年前修复闭包语义之外，我还没有看到在Python中重新定义它的严肃建议。

编码清晰度的降低——应该避免吗?

如果你用对了，也不会不太清楚。相反，拥有更多可用的语言结构可以增加清晰度。

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

就像缓冲区溢出?哇。如果您认为lambda是一个“维护噩梦”，我无法想象您将如何使用它。