任何人只要长时间摆弄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行将是“混合”的,即部分绑定(函数对象)将在定义时发生,部分绑定(默认参数的赋值)将在函数调用时发生。

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


当前回答

文件的相关部分:

执行函数定义时,从左到右计算默认参数值。这意味着在定义函数时,表达式将求值一次,并且每次调用都使用相同的“预计算”值。当默认参数是可变对象(例如列表或字典)时,这一点尤其重要:如果函数修改了对象(例如,通过将项附加到列表),则默认值实际上已被修改。这通常不是预期的。解决此问题的一种方法是使用None作为默认值,并在函数体中显式测试它,例如:def whats_on_the_telly(企鹅=无):如果企鹅为无:企鹅=[]企鹅追加(“动物园的财产”)返回企鹅

其他回答

我对Python解释器的内部工作一无所知(我也不是编译器和解释器的专家),所以如果我提出任何不合理或不可能的建议,不要怪我。

假设python对象是可变的,我认为在设计默认参数时应该考虑到这一点。实例化列表时:

a = []

你希望得到一个新的列表。

为什么a=[]

def x(a=[]):

在函数定义而不是调用上实例化新列表?这就像你在问“如果用户不提供参数,那么实例化一个新列表,并将其作为调用者生成的列表使用”。我认为这是模棱两可的:

def x(a=datetime.datetime.now()):

用户,是否希望a默认为定义或执行x时对应的日期时间?在本例中,与前一例一样,我将保持与默认参数“赋值”是函数的第一条指令(函数调用时调用datetime.now())相同的行为。另一方面,如果用户想要定义时间映射,他可以写:

b = datetime.datetime.now()
def x(a=b):

我知道,我知道:这是一个结束。或者Python可以提供一个关键字来强制定义时间绑定:

def x(static a=b):

假设您有以下代码

fruits = ("apples", "bananas", "loganberries")

def eat(food=fruits):
    ...

当我看到eat的声明时,最不令人惊讶的是,如果没有给定第一个参数,它将等于元组(“apples”、“banans”、“loganberries”)

然而,假设稍后在代码中

def some_random_function():
    global fruits
    fruits = ("blueberries", "mangos")

那么,如果默认参数是在函数执行时绑定的,而不是在函数声明时绑定的话,我会惊讶地发现(以一种非常糟糕的方式)水果已经被更改了。这将比发现上面的foo函数正在改变列表更让IMO惊讶。

真正的问题在于可变变量,所有语言在某种程度上都存在这个问题。这里有一个问题:假设在Java中我有以下代码:

StringBuffer s = new StringBuffer("Hello World!");
Map<StringBuffer,Integer> counts = new HashMap<StringBuffer,Integer>();
counts.put(s, 5);
s.append("!!!!");
System.out.println( counts.get(s) );  // does this work?

现在,我的映射是使用StringBuffer键在放置到映射中时的值,还是通过引用存储该键?不管怎样,都有人感到惊讶;或者是试图使用与放入对象的值相同的值将对象从Map中取出的人,或者是即使他们使用的键实际上与用于将其放入映射中的对象相同,但似乎无法检索对象的人(这实际上就是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的行为在这里代表了一个设计缺陷。

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

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

(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很好用。