鼓励使用命名参数

通过减少已建立的关键字参数语法可能引起的视觉噪音，此语法将鼓励使用命名参数，从而提高可读性并减少参数位置颠倒引起的错误。

减少冗余

通过最大限度地减少视觉噪音，并在某些情况下减少代码行数，我们可以提高可读性。

鼓励一致的变量名

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

突出不遵循此模式的参数

使用现有语法，许多参数从本地上下文转发的函数调用可能会由于视觉噪音而容易忽略其他参数值。例如

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 += 1 是 x = x + 1（当 x 是整数时）的糖一样。这并不是“一种新的”传递参数的方式，而是同一方式的一种更具可读性的符号。

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

在绝大多数情况下，NameError 会使错误变得清晰。如果来自更广泛范围的变量与原始变量同名，可能会导致混淆，因此不会引发 NameError。然而，使用当前语法的关键字参数也可能出现此问题（尽管可以说，这种语法糖可能会使其更难发现）。此外，在不同作用域中具有相同名称的变量通常被认为是糟糕的做法，并且会被 linters 劝阻。

代码编辑器可以通过静态分析高亮显示问题——f(x=) 等同于编写 f(x=x)。如果 x 不存在，现代编辑器会轻松地高亮显示问题。

此语法增加了耦合

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

然而，如果两个变量具有不同的语义，这表明不应使用此功能（因为它鼓励一致性），或者可能应该重命名其中一个或两个变量。

使用纯文本编辑器

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

当使用“查找-替换”方法重命名变量时，在使用此语法的地方，开发人员会在调用时遇到函数参数（就像未使用此语法时一样）。此时，他们可以像平常一样决定是更新参数还是展开为完整的 f(x=x) 语法。

与当前语法一样，“查找-替换全部”方法将失败，因为在绝大多数情况下，关键字参数在函数定义时不存在。

如果开发人员不更改参数名称并忘记更新其值，则通常会引发 NameError，如 Renaming the variable in the calling context will break the code 中所述。

IDE的建议

为响应社区反馈，我们在此提供有关 IDE 如何处理此语法的建议。然而，我们将其留给开发 IDE 的领域专家自行决定。

通过认识到 f(x=) 只是 f(x=x) 的语法糖，并且应与当前情况相同地处理，大多数考虑因素都变得简单了。