任何人只要长时间摆弄Python,都会被以下问题所困扰(或撕成碎片):

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

Python新手希望这个没有参数的函数总是返回一个只有一个元素的列表:[5]。结果却非常不同,非常令人惊讶(对于新手来说):

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

我的一位经理曾第一次接触到这个功能,并称其为语言的“戏剧性设计缺陷”。我回答说,这种行为有一个潜在的解释,如果你不了解其内部,这确实非常令人困惑和意外。然而,我无法(对自己)回答以下问题:在函数定义时而不是在函数执行时绑定默认参数的原因是什么?我怀疑有经验的行为是否有实际用途(谁真的在C中使用了静态变量,而没有滋生bug?)

编辑:

Baczek举了一个有趣的例子。连同您的大多数评论,特别是Utaal的评论,我进一步阐述了:

>>> def a():
...     print("a executed")
...     return []
... 
>>>            
>>> def b(x=a()):
...     x.append(5)
...     print(x)
... 
a executed
>>> b()
[5]
>>> b()
[5, 5]

在我看来,设计决策似乎与将参数范围放在哪里有关:放在函数内部,还是与函数“一起”?

在函数内部进行绑定意味着当函数被调用而不是被定义时,x被有效地绑定到指定的默认值,这将带来一个严重的缺陷:def行将是“混合”的,即部分绑定(函数对象)将在定义时发生,部分绑定(默认参数的赋值)将在函数调用时发生。

实际行为更加一致:当执行该行时,该行的所有内容都会得到求值,这意味着在函数定义时。


当前回答

嗯,原因很简单,绑定是在代码执行时完成的,函数定义是执行的,嗯。。。当定义函数时。

比较一下:

class BananaBunch:
    bananas = []

    def addBanana(self, banana):
        self.bananas.append(banana)

这段代码遭遇了完全相同的意外事件。香蕉是一个类属性,因此,当您向它添加内容时,它会添加到该类的所有实例中。原因完全相同。

这只是“它是如何工作的”,在函数情况下使它以不同的方式工作可能会很复杂,在类情况下可能是不可能的,或者至少会大大降低对象实例化的速度,因为您必须保留类代码,并在创建对象时执行它。

是的,这是出乎意料的。但一旦一分钱下降,它就完全符合Python的工作原理。事实上,这是一个很好的教学辅助工具,一旦你了解了为什么会发生这种情况,你就会更好地了解python。

也就是说,它应该在任何好的Python教程中占据突出位置。因为正如你提到的,每个人迟早都会遇到这个问题。

其他回答

有一种简单的方法可以理解为什么会发生这种情况。

Python在命名空间中从上到下执行代码。

“内部”恰恰体现了这一规则。

这种选择的原因是“让语言适合你的头脑”。所有奇怪的角落情况都倾向于简化为在命名空间中执行代码:默认免疫、嵌套函数、类(编译完成时有一点补丁)、自参数等。类似地,复杂语法可以用简单语法编写:a.foo(…)只是a.lookup('fo').__call__(a,…)。这适用于列表理解;装饰工;元类;以及更多。这可以让你看到一个近乎完美的奇怪角落。这种语言适合你的头脑。

你应该坚持下去。学习Python对语言有一段时间的不满,但它会让你感到舒服。这是我用过的唯一一种语言,你越看角落里的案例,它就越简单。

继续黑客攻击!做好记录。

对于您的特定代码,太详细了:

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

foo()

是一个语句,相当于:

开始创建代码对象。现在就解释(a=[])。[]是参数a的默认值。它是列表类型的,因为[]总是这样。将:之后的所有代码编译成Python字节码,并将其粘贴到另一个列表中。使用“code”字段中的参数和代码创建可调用字典将可调用对象添加到“foo”字段中的当前命名空间。

然后,它转到下一行foo()。

它不是保留字,所以在名称空间中查找它。调用函数,该函数将使用列表作为默认参数。开始在其命名空间中执行其字节码。append不会创建新列表,因此旧列表被修改。

我将演示一种将默认列表值传递给函数的替代结构(它与字典同样适用)。

正如其他人广泛评论的那样,列表参数在定义时绑定到函数,而不是在执行时。由于列表和字典是可变的,因此对该参数的任何更改都将影响对该函数的其他调用。因此,对函数的后续调用将接收此共享列表,该列表可能已被对函数的任何其他调用更改。更糟糕的是,两个参数同时使用该函数的共享参数,而忽略了另一个参数所做的更改。

错误的方法(可能…):

def foo(list_arg=[5]):
    return list_arg

a = foo()
a.append(6)
>>> a
[5, 6]

b = foo()
b.append(7)
# The value of 6 appended to variable 'a' is now part of the list held by 'b'.
>>> b
[5, 6, 7]  

# Although 'a' is expecting to receive 6 (the last element it appended to the list),
# it actually receives the last element appended to the shared list.
# It thus receives the value 7 previously appended by 'b'.
>>> a.pop()             
7

您可以使用id:

>>> id(a)
5347866528

>>> id(b)
5347866528

根据Brett Slatkin的《有效的Python:59种编写更好Python的具体方法》,第20项:使用None和Docstring指定动态默认参数(第48页)

在Python中实现所需结果的惯例是提供默认值None,并记录实际行为在docstring中。

此实现确保对函数的每个调用都接收默认列表或传递给函数的列表。

首选方法:

def foo(list_arg=None):
   """
   :param list_arg:  A list of input values. 
                     If none provided, used a list with a default value of 5.
   """
   if not list_arg:
       list_arg = [5]
   return list_arg

a = foo()
a.append(6)
>>> a
[5, 6]

b = foo()
b.append(7)
>>> b
[5, 7]

c = foo([10])
c.append(11)
>>> c
[10, 11]

“错误方法”可能有合法的用例,程序员希望共享默认列表参数,但这更可能是例外而不是规则。

如果考虑到以下因素,这种行为并不奇怪:

尝试赋值时只读类属性的行为,以及函数是对象(在公认的答案中解释得很好)。

(2)的作用已在本主题中广泛讨论。(1) 很可能是令人惊讶的原因,因为这种行为在来自其他语言时并不“直观”。

(1) 在Python教程中对类进行了描述。尝试将值分配给只读类属性时:

…在最内部范围之外找到的所有变量都是只读(尝试写入这样的变量只会创建一个最内部范围中的新局部变量,保留相同的命名的外部变量保持不变)。

回顾最初的示例,并考虑以上几点:

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

这里foo是一个对象,a是foo的一个属性(在foo.func_defs[0]中可用)。由于a是一个列表,因此a是可变的,因此是foo读写属性。当函数实例化时,它被初始化为签名指定的空列表,并且只要函数对象存在,它就可用于读取和写入。

在不覆盖默认值的情况下调用foo使用foo.func_defs中的默认值。在这种情况下,foo.func_descfs[0]用于函数内对象的代码范围。更改foo.func_defs[0],它是foo对象的一部分,在执行foo中的代码之间持续存在。

现在,将其与文档中关于模拟其他语言的默认参数行为的示例进行比较,以便每次执行函数时都使用函数签名默认值:

def foo(a, L=None):
    if L is None:
        L = []
    L.append(a)
    return L

考虑到(1)和(2),可以看出为什么这会实现所需的行为:

当foo函数对象被实例化时,foo.func_defs[0]被设置为None,这是一个不可变的对象。当函数以默认值执行时(函数调用中没有为L指定参数),foo.func_defs[0](None)在本地作用域中可用为L。当L=[]时,foo.func_defs[0]处的赋值无法成功,因为该属性是只读的。根据(1),在局部作用域中创建一个新的局部变量(也称为L),并用于函数调用的其余部分。因此,对于未来的foo调用,foo.func_defs[0]保持不变。

这可能是真的:

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

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

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

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

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

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

嗯,原因很简单,绑定是在代码执行时完成的,函数定义是执行的,嗯。。。当定义函数时。

比较一下:

class BananaBunch:
    bananas = []

    def addBanana(self, banana):
        self.bananas.append(banana)

这段代码遭遇了完全相同的意外事件。香蕉是一个类属性,因此,当您向它添加内容时,它会添加到该类的所有实例中。原因完全相同。

这只是“它是如何工作的”,在函数情况下使它以不同的方式工作可能会很复杂,在类情况下可能是不可能的,或者至少会大大降低对象实例化的速度,因为您必须保留类代码,并在创建对象时执行它。

是的,这是出乎意料的。但一旦一分钱下降,它就完全符合Python的工作原理。事实上,这是一个很好的教学辅助工具,一旦你了解了为什么会发生这种情况,你就会更好地了解python。

也就是说,它应该在任何好的Python教程中占据突出位置。因为正如你提到的,每个人迟早都会遇到这个问题。