鼓励使用命名参数

这种语法将鼓励使用命名参数，从而提高可读性并减少参数换位造成的错误。

减少冗余

通过最小化视觉噪声，在某些情况下甚至减少代码行数，我们可以提高可读性。

鼓励一致的变量名

一个常见的问题是，语义上相同的变量在不同的上下文中具有不同的名称。这种语法将鼓励作者在调用函数时使用与参数名相同的变量名，这将提高使用的变量名的一致性，从而也提高可读性。

突出显示不遵循此模式的参数

使用当前语法，如果许多参数从本地上下文转发，则由于视觉噪声，其他参数值可能很容易被忽略。例如

add_middleware(
    excluded_urls=excluded_urls,
    server_request=server_request,
    client_request=client_request,
    client_response=client_response,
    span_details=_get_span_details(),
    tracer=tracer,
    meter=meter,
)

使用这种语法，异常参数更容易识别

add_middleware(
    excluded_urls=,
    server_request=,
    client_request=,
    client_response=,
    span_details=_get_span_details(),
    tracer=,
    meter=,
)

字典构造的适用性

这种语法可以应用于字典构造，其中经常出现类似的模式（字典键与分配为其值的变量名称相同），{"x": x, "y": y} 或 dict(x=x, y=y)。有了这个功能，现在可以很容易地写成 dict(x=, y=)。是否在字典文字中进一步支持类似的语法是一个超出本 PEP 范围的开放性问题。

f(a, b, *, x)

在一些场合，人们提出过借用关键字参数函数定义的语法。

支持这个提议

• 这种语法因其在函数定义中要求关键字参数而为人熟知。
• 一项针对 Python 开发者的调查显示，这是在所有提议的语法中，第二受欢迎的一种。

然而，我们反对

• 对于任何给定的参数，从本地上下文不清楚它是位置参数还是命名参数。 在一个很长的参数列表中，很容易错过 *，并且命名参数可能被误读为位置参数，反之亦然。
• 尚不清楚是否允许省略值的关键字参数跟随 *。 如果是，那么它们之间的相对位置将令人困惑地随意，但如果不是，那么不同类型关键字参数之间会强制执行一个任意的分组，并且如果只更改了一个名称（参数或其值），则需要重新排序参数。
• 在函数调用中使用 * 已经确立，这个提议会引入一个新的效果，这可能会造成混淆。 例如， f(a, *x, y) 的含义将不同于 f(a, *, x, y)。

f(=x)

支持这种形式

• 前缀运算符更类似于函数调用中已有的 *args 和 **kwargs 语法。
• 当参数垂直排列时，它会更多地引起人们的注意。 特别是，如果参数长度不同，则更难在末尾找到等号。 此外，由于 Python 从左到右读取，因此使用此功能对于读者来说更清晰。

相反

• 虽然前缀版本在视觉上更明显，但在实践中，此功能没有必要像典型命名参数那样大声地宣告自己的存在。 当我们读到 = 时，很明显值会自动填充，就像在典型的关键字参数情况下一样。
• 语义上，这种形式传达了“这里有一个值，填入参数”，这不是我们想表达的意思。
• 它与 f-string 语法不太相似。
• 不太明显的是，任意的表达式是无效的，例如 f(=a + b)。

f(%x) 或 f(:x) 或 f(.x)

已经提出了几种这种语法的变体，其中前缀形式用其他字符替换了 =。 然而，没有一种形式获得了足够的关注，并且与 = 相比，符号的选择显得任意。 此外，在现有的语言特性（例如 f-string）或其他语言（例如 Ruby）方面，这种做法没有先例。

语法很丑

这个反对意见是最常见的。 相反，我们认为

• 这个反对意见是主观的，许多社区成员不认同。
• 一个几乎相同的语法已经为 f-string 确立。
• 程序员将像往常一样，随着时间的推移而适应。

该特性令人困惑

我们认为

• 引入新功能通常会暂时产生这种影响。
• 语法与已有的 f'{x=}' 语法非常相似。
• 此功能和语法在其他流行的现代语言中很常见。
• 将 x= 扩展为 x=x 事实上是一个微不足道的功能，从本质上来说，它比 *arg 和 **kwarg 扩展要简单得多。
• 这种特殊的语法形式已经多次被独立提出，表明它是最显而易见的[1] [2] [6]。

该特性不够明确

我们认识到，从明显的意义上说，参数值在这个提议的语法中是“隐式”的。 然而，我们并不认为这就是 Python 之禅想要阻止的。

从我们认为 Python 之禅所指的意义上说，关键字参数（例如）比省略了参数名称且无法从本地上下文判断其名称的位置参数更明确。 相反，整数的语法糖 x += 1 在这种意义上并不比 x = x + 1 更隐式，即使变量在右侧被省略了，因为从本地上下文立即清楚它是什么。

本 PEP 中提议的语法与 x += 1 示例更为类似（尽管更简单，因为我们没有提议引入新的操作）。 此外，引入这种语法糖应该鼓励使用关键字参数而不是位置参数，从而使典型的 Python 代码库在总体上更明确。

该特性增加了另一种做事方式

同样的论点可以用来反对所有语法更改。 这只是一个简单的语法糖，就像当 x 是一个整数时， x += 1 是 x = x + 1 的糖一样。 这并不等同于传递参数的“新方式”，而是一种更可读的符号，用于表示相同的方式。

在调用上下文中重命名变量将破坏代码

在大多数情况下，一个 NameError 会使错误很明显。 如果一个来自更广泛范围内的变量与原始变量具有相同的名称，可能会造成混淆，因此不会引发 NameError。 然而，这个问题也可能发生在使用当前语法的关键字参数中（可以说，这种语法糖可能会使它更难发现）。 此外，在不同的范围内拥有具有相同名称的变量通常被认为是不好的做法，并且被代码检查器阻止。

代码编辑器可以根据静态分析来突出显示问题 - f(x=) 等效于编写 f(x=x)。 如果 x 不存在，现代编辑器可以轻松地突出显示该问题。

这种语法增加了耦合

我们认识到，像往常一样，所有语法都有被误用的可能性，因此应该谨慎使用它们来改进代码库。 在这种情况下，如果一个参数及其值在两种情况下都具有相同的语义，那么这可能表明使用这种新语法是合适的，并且将有助于改善无意中不同步的风险，从而损害可读性。

但是，如果两个变量具有不同的语义，那么这可能表明不应该使用此功能来鼓励一致性，甚至应该对它们进行重命名。

使用纯文本编辑器

使用纯文本编辑器进行编辑通常不会受到影响。

在使用“查找-替换”方法重命名变量时，如果使用了这种语法，开发人员会在调用时遇到函数参数（就像没有使用这种语法时一样）。 此时，他们可以像往常一样决定是否也更新参数，或者扩展到完整的 f(x=x) 语法。

与当前语法类似，‘全部查找替换’方法会失败，因为在大多数情况下，函数定义时关键字参数不存在。

如果开发人员保留参数名称不变并忘记更新其值，通常会引发一个 NameError，如 上述 所述。

IDE 的建议

为了回应社区反馈，我们提供了一些关于 IDE 如何处理这种语法的建议。但是，我们当然尊重开发 IDE 的领域专家使用他们自己的判断。

大多数考虑因素都变得简单，因为认识到 f(x=) 只是 f(x=x) 的语法糖，应该像现在一样对待。