我认为这个问题的答案在于python如何将数据传递给参数（通过值或引用传递），而不是可变性或python如何处理“def”语句。

简要介绍。首先，python中有两种数据类型，一种是简单的基本数据类型，如数字，另一种数据类型是对象。第二，当将数据传递给参数时，python按值传递基本数据类型，即将值的本地副本传递给本地变量，但按引用传递对象，即指向对象的指针。

承认以上两点，让我们解释一下python代码发生了什么。这只是因为通过对象的引用传递，但与可变/不可变无关，或者可以说“def”语句在定义时只执行一次。

[]是一个对象，因此python将[]的引用传递给a，即a只是指向[]的指针，该指针作为对象存储在内存中。只有一个[]副本，但是有很多引用。对于第一个foo（），列表[]通过append方法更改为1。但请注意，列表对象只有一个副本，该对象现在变为1。当运行第二个foo（）时，effbot网页所说的（不再计算项目）是错误的。a被评估为列表对象，尽管现在对象的内容是1。这是通过引用传递的效果！foo（3）的结果可以很容易地以相同的方式导出。

为了进一步验证我的答案，让我们看看另外两个代码。

=====第2名========

def foo(x, items=None):
    if items is None:
        items = []
    items.append(x)
    return items

foo(1)  #return [1]
foo(2)  #return [2]
foo(3)  #return [3]

[]是一个对象，None也是（前者是可变的，后者是不可变的。但可变性与问题无关）。空间中没有任何东西，但我们知道它在那里，那里只有一个“无”的副本。因此，每次调用foo时，项都会被求值为None（而不是某个只求值一次的答案），明确地说，引用（或地址）为None。然后在foo中，item被更改为[]，即指向另一个具有不同地址的对象。

=====第3位=======

def foo(x, items=[]):
    items.append(x)
    return items

foo(1)    # returns [1]
foo(2,[]) # returns [2]
foo(3)    # returns [1,3]

foo（1）的调用使项指向一个地址为11111111的列表对象[]。在后续的foo函数中，列表的内容被更改为1，但地址没有更改，仍然是11111111。然后foo（2，[]）就要来了。虽然foo（2，[]）中的[]与调用foo（1）时的默认参数[]具有相同的内容，但它们的地址不同！因为我们显式地提供了参数，所以项必须获取这个新[]的地址，比如2222222，并在进行一些更改后返回它。现在执行foo（3）。由于只提供了x，因此项必须再次采用其默认值。默认值是多少？它是在定义foo函数时设置的：位于11111111中的列表对象。因此，项目被评估为具有元素1的地址11111111。位于2222222的列表还包含一个元素2，但它不再由项目指向。因此，追加3将生成项目[1,3]。

从上面的解释中，我们可以看到，在接受的答案中推荐的effbot网页未能给出这个问题的相关答案。此外，我认为effbot网页中的一点是错误的。我认为关于UI.Button的代码是正确的：

for i in range(10):
    def callback():
        print "clicked button", i
    UI.Button("button %s" % i, callback)

每个按钮都可以保存一个不同的回调函数，该函数将显示不同的i值。我可以提供一个示例来说明这一点：

x=[]
for i in range(10):
    def callback():
        print(i)
    x.append(callback) 

如果我们执行x[7]（），我们将得到预期的7，x[9]（）将得到9，即i的另一个值。

您可以通过替换对象（以及与范围的关系）来解决此问题：

def foo(a=[]):
    a = list(a)
    a.append(5)
    return a

丑陋，但它奏效了。

这实际上与默认值无关，只是当您使用可变默认值编写函数时，它通常会出现意外行为。

>>> def foo(a):
    a.append(5)
    print a

>>> a  = [5]
>>> foo(a)
[5, 5]
>>> foo(a)
[5, 5, 5]
>>> foo(a)
[5, 5, 5, 5]
>>> foo(a)
[5, 5, 5, 5, 5]

在这段代码中看不到默认值，但您会遇到完全相同的问题。

问题是，foo正在修改从调用方传入的可变变量，而调用方并不期望这样做。如果函数的调用类似于append_5，那么这样的代码就可以了；那么调用者将调用函数以修改传入的值，并且行为是预期的。但是这样的函数不太可能采用默认参数，并且可能不会返回列表（因为调用者已经有了对该列表的引用；它刚刚传入的那个）。

您的原始foo（带有默认参数）不应该修改a，无论它是显式传入还是获得默认值。除非从上下文/名称/文档中可以清楚地看到参数应该被修改，否则代码应该保留可变参数。无论我们是否使用Python，也不管是否涉及默认参数，使用作为参数传入的可变值作为本地临时变量是一个非常糟糕的想法。

如果在计算过程中需要破坏性地操作本地临时变量，并且需要从参数值开始操作，则需要创建副本。

这个“bug”给了我很多加班时间！但我开始看到它的潜在用途（但我还是希望它在执行时使用）

我会给你一个我认为有用的例子。

def example(errors=[]):
    # statements
    # Something went wrong
    mistake = True
    if mistake:
        tryToFixIt(errors)
        # Didn't work.. let's try again
        tryToFixItAnotherway(errors)
        # This time it worked
    return errors

def tryToFixIt(err):
    err.append('Attempt to fix it')

def tryToFixItAnotherway(err):
    err.append('Attempt to fix it by another way')

def main():
    for item in range(2):
        errors = example()
    print '\n'.join(errors)

main()

打印以下内容

Attempt to fix it
Attempt to fix it by another way
Attempt to fix it
Attempt to fix it by another way

这可能是真的：

有人正在使用每种语言/库功能，并且在这里改变行为是不明智的，但是

坚持上述两个特征是完全一致的，并且仍然提出另一点：

这是一个令人困惑的特性，在Python中很不幸。

其他答案，或至少其中一些答案，要么是第1点和第2点，但不是第3点，要么就是第3点而淡化第1点或第2点。但这三个都是真的。

在这里，在中途换马可能会导致严重的破坏，而且通过改变Python来直观地处理Stefano的开头片段可能会产生更多的问题。也许有人很了解Python的内部结构，就能解释一个后果雷区。然而

现有的行为不是Pythonic的，Python之所以成功，是因为该语言几乎没有违反最不令人惊讶的原则。这是一个真正的问题，无论根除它是否明智。这是一种设计缺陷。如果你通过尝试追踪行为来更好地理解语言，我可以说C++完成了所有这些以及更多的工作；例如，通过导航细微的指针错误，您可以学到很多东西。但这并不是Pythonic的：那些对Python足够关心并在这种行为面前坚持不懈的人都是被这种语言所吸引的人，因为Python比其他语言的惊喜要少得多。当他们惊讶于用很少的时间就能让一些东西发挥作用——而不是因为设计失误——我的意思是，隐藏的逻辑谜题——这违背了程序员的直觉时，达博人和好奇者就成了Python爱好者，因为Python很好用。

是的，这是Python中的一个设计缺陷

我看过所有其他答案，但我不相信。这种设计确实违反了最小惊讶的原则。

默认值可以设计为在调用函数时计算，而不是在定义函数时计算。Javascript是这样做的：

函数foo（a=[]）{a.推动（5）；返回a；}console.log（foo（））；//[5]console.log（foo（））；//[5]console.log（foo（））；//[5]

作为进一步证明这是一个设计缺陷的证据，Python核心开发人员目前正在讨论引入新语法来解决这个问题。请参阅本文：Python的后期绑定参数默认值。

为了进一步证明这是一个设计缺陷，如果你搜索“Python gotchas”，这个设计被称为gotcha，通常是列表中的第一个gotcha，在前9个Google结果（1、2、3、4、5、6、7、8、9）中。相反，如果你搜索“Javascript gotchas”，Javascript中默认参数的行为甚至一次都没有被提到过。

根据定义，Gotchas违反了最小惊讶的原则。它们令人惊讶。鉴于默认参数值的行为有着更高级的设计，不可避免的结论是Python的行为在这里代表了一个设计缺陷。