PEP 736 – 调用时关键字参数的速记语法

抽象

该 PEP 建议为普通 命名参数与变量名称相同的模式 对应于它的值。f(x=)f(x=x)

赋予动机

关键字参数语法可能会变得不必要的重复和冗长。

请考虑以下调用：

my_function(
  my_first_variable=my_first_variable,
  my_second_variable=my_second_variable,
  my_third_variable=my_third_variable,
)

关键字参数名称与其值的变量名称匹配的情况为 在所有主要的 Python 库中普遍存在。这种冗长和冗余 不鼓励使用命名参数，并通过增加视觉效果来降低可读性 噪声。

理由

有两种方法可以调用带有参数的函数：按位置调用函数和按 关键词。关键字参数通过显式提供许多好处，因此 提高可读性并最大限度地降低意外转置的风险。上 另一方面，立场论证通常只是为了尽量减少冗长 和视觉噪音。

我们认为，一个简单的句法糖用来简化这种常见的模式 这将带来许多好处：

鼓励使用命名变量

这种语法将鼓励使用命名变量，从而增加 可读性（显式优于隐式）并减少参数中的错误 调换。

减少冗长

通过最大限度地减少视觉噪音和在某些情况下的代码行，我们可以增加 可读性（可读性计数）。

鼓励一致的变量名称

一个常见的问题是语义上相同的变量具有不同的名称 取决于他们的上下文。这种语法会鼓励作者使用相同的语法 变量名称，当调用函数作为参数名称时，这将增加 所用变量名称的一致性，因此也是可读性的。

对字典构造的适用性

这种语法可以应用于字典构造，其中类似的 模式经常出现（如果字典键相同，则 变量赋值），或者 . 有了这个功能，现在也可以简单地写成 . 是否在字典文字中进一步支持类似的语法是一个开放的 问题超出了本 PEP 的范围。{"x": x, "y": y}dict(x=x, y=y)dict(x=, y=)

规范

我们建议引入句法糖，这样，如果一个关键词的值 函数调用中省略参数，推断参数的值 成为在调用范围内与该名称匹配的变量。

例如，函数调用：

my_function(my_first_variable=, my_second_variable=, my_third_variable=)

将完全等同于现有语法中的以下解释：

my_function(
  my_first_variable=my_first_variable,
  my_second_variable=my_second_variable,
  my_third_variable=my_third_variable,
)

如果调用作用域中没有与该名称匹配的变量，则 以与已建立的扩展语法相同的方式提出。NameError

此提案仅涉及函数调用;函数定义是 不受语法更改的影响。所有现有的有效语法保持不变。

向后兼容性

只添加了以前语法错误的新语法。不 修改现有有效语法。因此，拟议的更改是完全的 向后兼容。

安全隐患

此更改不会产生任何安全隐患。

如何教这个

程序员可以将此功能作为可选的缩写语法来了解，其中 教授关键字参数。Python 词汇表和教程可能会相应更新。

现有技术

Python 在 f 字符串插值中已经具有非常相似的功能，该功能被有效地扩展到 。f'{x=}'f'x={x}'

几种现代语言在函数调用期间提供类似的功能， 有时被称为“双关语”。例如：

• 在 Ruby 中，是  的句法糖。f(x:, y:)f(x: x, y: y)

• 在 ReasonML 中，是 的句法糖。f(~x, ~y)f(~x=x, ~y=y)

• 在 SystemVerilog 中，是的语法糖。(.mult, .mop1, .data);(.mult(mult), .mop1(mop1),  .data(data));

除了函数调用之外，还有更多语言提供类似的功能：

• 在 OCaml 中，是的句法糖。let+ x in …let+ x = x in …

• 在 JavaScript 中，是的语法糖。{ x, y }{x: x, y: y}

• 在 Rust 中，是 的简写。User { x, y }User {x: x, y: y}

适用性

我们使用此脚本分析了流行的 Python 库来计算：

• 关键字参数的数量是调用时的形式。f(x=x)

• 形式为 调用。f(x=x)

• 使用此语法糖可以保存的代码行数 以减少对换行的需要。scikit-学习

基于此，我们注意到关键字参数模式是 广泛使用，占所有关键字参数使用的 10-20%。f(x=x)

建议的语法

虽然这个功能已经多次被提出，但有几个 不同的形式我们选择提倡 出于以下原因，表格：f(x=)

• 这个特性在十年的时间里经常被提出，or是迄今为止最常见的语法。 这是一个强有力的指标，表明它是显而易见的符号。f(x=)f(=x)

• 建议的语法与 f-string 调试语法非常匹配 （建立 Python 风格）并具有几乎相同的目的。f'{var=}'

• 建议的语法与 Ruby 关键字参数完全类似 句法糖。

• 该语法易于实现，因为它是简单的语法糖。

• 与前缀形式（参见 Rejected Ideas）相比，这种语法 传达“这是一个参数，去找它的参数”，这是更多 考虑到命名参数的语义，这是合适的。

• 对 Python 开发人员的民意调查表明，这是提议的语法中最受欢迎的语法。

被拒绝的想法

已经提出了许多替代语法，但是除了或获得大量支持之外，没有其他语法。我们在这里列举一些 最受欢迎的替代方案以及我们最终拒绝它们的原因。f(=x)f(x=)

f（=x）

赞成这种形式：

• 前缀运算符更类似于函数调用的既定语法和语法。*args**kwargs

• 当参数垂直排列时，它会引起更多的注意。在 特别是，如果参数的长度不同，则更难找到 末尾的等号。此外，由于 Python 是从左到右阅读的，因此使用 这个功能对读者来说更清楚。

恰恰相反：

• 虽然前缀版本在视觉上更响亮，但实际上，没有必要 此功能比典型的命名参数更能喊出它的存在。由 我们读到的时间很清楚，该值已填写 自动，就像在典型的关键字参数案例中值一样。=

• 从语义上讲，此表单传达“这是一个值，填写参数”。

• 这不是我们想要传达的。

• 与 f-string 语法不太相似。

• 不太明显的是任意表达式无效，例如 .f(=a+b)

或 或

已经提出了这种语法的几种风格，其前缀形式 用另一个字符替换 .但是，没有获得这样的形式 牵引力和符号的选择与 相比似乎是任意的。 此外，就现有语言功能而言，先例较少 （如 f-string）或其他语言（如 Ruby）。==

f(a, b, *, x)

在一些情况下，这个想法已经浮出水面，借用了 仅关键字函数定义。这比 或 变体，但不亚于.f(%x)f(x=)

但是，我们反对：

• 对于任何给定的论点，从本地上下文中不太清楚它是否是 位置或命名。在很长的参数列表中很容易被遗漏 命名参数可以读作位置参数，反之亦然。*

• 目前尚不清楚未省略该值的关键字参数是否可以 按照 .如果是这样，那么它们的相对位置将不一致，但是 如果没有，则在不同类型的 关键字参数。*

反对

对于引入这种句法，只有少数几个强硬的反对意见 糖。大多数不赞成这一功能的人都属于“我”的阵营 不会使用它'。但是，在关于此功能的广泛讨论中， 以下反对意见是最常见的：

语法很丑陋

这种反对意见是迄今为止最常见的。相反，我们认为：

• 这种反对意见是主观的，许多社区成员不同意。

• 已经为 f 字符串建立了几乎相同的语法。

• 程序员将一如既往地随着时间的推移进行调整。

该功能令人困惑

我们认为：

• 引入新功能通常会暂时产生这种影响。

• 语法与已建立的语法非常相似。f'{x=}'

• 该功能和语法与其他流行的现代语言相似。

• to 的扩展实际上是一个微不足道的功能，并且本质上是 比和扩展要简单得多。x=x=x*arg**kwarg

• 这种特殊的句法形式已经独立地在许多 场合，表明它是最明显的。

该功能不是明确的

这是基于对Python禅宗的误解。关键字参数是 从根本上比位置更明确，其中参数赋值是 仅在函数定义中可见。相反，所提出的句法 糖包含已建立的关键字所传达的所有信息 参数语法，但没有冗余。此外，引入这个 句法糖激励使用关键字参数，使典型的 Python 代码库更明确。

该功能增加了另一种做事方式

可以对所有语法更改提出相同的论点。这是一个简单的 句法糖，就像糖一样 when 是一个 整数。这并不等同于传递论点的“新方式”，而是一种更 以同样的方式进行可读表示。x += 1x = x + 1x

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

A 会非常清楚地说明错误。此外，文本编辑器 可以基于静态分析来强调这一点——完全等价 写.如果不存在，现代编辑器没有问题 突出显示问题。NameErrorf(x=)f(x=x)x

建议

与任何其他语言功能一样，程序员应该练习自己的 判断是否在任何给定的上下文中使用它。我们不建议 强制执行规则以在可能适用的所有情况下使用该功能。

版权

本文档位于公共领域或 CC0-1.0-通用许可证，以更宽松者为准。

The End