TypeScript

在 TypeScript 中，函数类型以几乎与我们提议的语法相同的语法表示，但箭头标记是 =>，并且参数带有名称

(x: int, y: str) => bool

参数的名称实际上与类型无关。所以，例如，这是一个相同的可调用类型

(a: int, b: str) => bool

Kotlin

Kotlin 中的函数类型允许与我们提议的语法完全相同的语法，例如

(Int, String) -> Bool

它还允许选择性地为参数添加名称，例如

(x: Int, y: String) -> Bool

与 TypeScript 一样，参数名称（如果提供）仅用于文档目的，不是类型本身的一部分。

Scala

Scala 使用 => 箭头表示函数类型。除此之外，它们的语法与我们提议的语法相同，例如

(Int, String) => Bool

Scala 像 Python 一样，能够按名称提供函数参数。函数类型可以选择性地包含名称，例如

(x: Int, y: String) => Bool

与 TypeScript 和 Kotlin 不同，如果提供了名称，这些名称就是类型的一部分——任何实现该类型的函数都必须使用相同的名称。这与我们在 已拒绝的替代方案 部分描述的扩展语法提案类似。

函数定义与可调用类型注解

在上面列出的所有语言中，函数定义的类型注解使用 : 而不是 ->。例如，在 TypeScript 中，一个简单的 add 函数看起来像这样

function higher_order(fn: (a: string) => string): string {
  return fn("Hello, World");
}

Scala 和 Kotlin 使用本质上相同的 : 语法用于返回注解。冒号在这些语言中是有意义的，因为它们都使用冒号来表示参数和变量的类型注解，返回类型的用法与之类似。

在 Python 中，我们使用冒号来表示函数体的开始，使用箭头表示返回注解。因此，即使我们的提案在表面上与其他语言相同，上下文也不同。在阅读包含可调用类型的函数定义时，Python 中存在更多混淆的可能性。

这是我们正在为草案 PEP 征求反馈的关键问题；我们提出的一个想法是改用 =>，以方便区分。

ML 语言家族

ML 家族的语言，包括 F#、OCaml 和 Haskell，都使用 -> 来表示函数类型。它们都使用无括号的语法和多个箭头，例如在 Haskell 中

Integer -> String -> Bool

使用多个箭头（这与我们的提案不同）对于该家族的语言来说是有意义的，因为它们使用自动 柯里化 函数参数，这意味着一个多参数函数表现得像一个返回函数的单参数函数。

→ 的优先级

→ 在类型和函数签名中，都比其他运算符的绑定更松散，因此以下两个可调用类型是等效的

(int) -> str | bool
(int) -> (str | bool)

→ 在类型和函数签名中，都向右关联。因此，以下对是等效的

(int) -> (str) -> bool
(int) -> ((str) -> bool)

def f() -> (int, str) -> bool: pass
def f() -> ((int, str) -> bool): pass

def f() -> (int) -> (str) -> bool: pass
def f() -> ((int) -> ((str) -> bool)): pass

因为运算符的绑定比 → 更紧密，所以当箭头类型打算作为 | 等运算符的参数时，需要括号。

(int) -> () -> int | () -> bool      # syntax error!
(int) -> (() -> int) | (() -> bool)  # okay

我们讨论了所有这些行为，并认为它们是可取的

• 并集类型（根据 PEP 604 表示为 A | B）在函数签名返回中是有效的，因此我们需要允许在返回位置使用运算符以保持一致性。
• 鉴于运算符的绑定比 → 更紧密，所以像 bool | () -> bool 这样的类型必须是语法错误，这是正确的。我们应该确保错误消息清晰，因为这可能是一个常见的错误。
• 将 → 向右关联，而不是要求显式括号，与其他语言（如 TypeScript）一致，并尊重有效表达式通常可以互换使用的原则。

async 关键字

所有绑定规则仍然适用于异步可调用类型

(int) -> async (float) -> str | bool
(int) -> (async (float) -> (str | bool))

def f() -> async (int, str) -> bool: pass
def f() -> (async (int, str) -> bool): pass

def f() -> async (int) -> async (str) -> bool: pass
def f() -> (async (int) -> (async (str) -> bool)): pass

尾部逗号

• 遵循函数签名的先例，在空参数列表中放置逗号是无效的：(,) -> bool 是一个语法错误。
• 再次遵循先例，尾部逗号在其他情况下始终是允许的

  ((int,) -> bool == (int) -> bool
  ((int, **P,) -> bool == (int, **P) -> bool
  ((...,) -> bool) == ((...) -> bool)
  

允许尾部逗号也为自动格式化程序提供了更多灵活性，当将可调用类型拆分到多行时，这在遵循标准 Python 空白规则时始终是合法的。

禁止将 ... 用作参数类型

在正常情况下，任何有效表达式都允许在我们需要类型注解的位置，而 `...` 是一个有效表达式。这在语义上永远不是有效的，并且所有类型检查器都会拒绝它，但如果我们不明确阻止它，语法是允许的。

由于 `...` 作为类型没有任何意义，并且存在可用性问题，我们的语法规则排除了它，因此以下是语法错误

(int, ...) -> bool

我们决定这样做是有充分理由的

• 对于任何有效类型 T，(...) -> bool 的语义与 (T) -> bool 不同：(...) 是表示 AnyArguments 的特殊形式，而 T 是参数列表中的类型参数。
• `...` 在存根和回调协议中用作占位符默认值，以表示可选参数。允许它出现在类型位置很容易导致混淆，甚至可能因为拼写错误而产生错误。
• 在 `tuple` 泛型类型中，我们专门处理 `...` 表示“更多相同”，例如 tuple[int, ...] 表示包含一个或多个整数的元组。我们在可调用类型中不以类似方式使用 `...`，因此为了避免误解，阻止这样做是有意义的。

与 * 和 ** 其他可能用法的兼容性

使用 `**P` 支持 PEP 612 `ParamSpec` 规则排除了任何未来使用裸 **<some_type> 来类型化 kwargs 的提案。这似乎是可以接受的，因为

• 如果我们确实想要这样的语法，最好还是要求一个参数名。这也会使类型看起来更像函数签名。换句话说，如果我们支持在可调用类型中类型化 `kwargs`，我们更倾向于 (int, **kwargs: str) 而不是 (int, **str)。
• PEP 646 解包语法将排除使用 `*<some_type>` 来表示 `args`。`kwargs` 的情况足够相似，这使得我们不会使用裸 `**<some_type>`。

与基于箭头的 lambda 语法的兼容性

据我们所知，目前没有关于箭头风格 lambda 语法的活跃讨论，但我们仍然值得考虑采纳此提案将排除哪些可能性。

如果采纳相同的基于括号的 `->` 箭头语法用于 lambda，例如 (x, y) -> x + y 来表示 lambda x, y: x + y，这与本提案不兼容。

我们的观点是，如果我们将来想要 lambda 的箭头语法，那么使用 `=>` 会是更好的选择，例如 (x, y) => x + y。许多语言对 lambda 和可调用类型使用相同的箭头标记，但 Python 独特之处在于类型是表达式，并且必须评估为运行时值。我们认为这值得使用单独的标记，考虑到函数签名中已使用的 `->` 表示返回类型，对于可调用类型使用 `->`，对于 lambda 使用 `=>` 会更连贯。

评估和结构化 API

我们打算创建新的内置类型，新的 AST 节点将评估为这些类型，并将它们暴露在 `types` 模块中。

我们的计划是公开一个结构化的 API，就好像它们是这样定义的

class CallableType:
    is_async: bool
    arguments: Ellipsis | tuple[CallableTypeArgument]
    return_type: object

class CallableTypeArgument:
    kind: CallableTypeArgumentKind
    annotation: object

@enum.global_enum
class CallableTypeArgumentKind(enum.IntEnum):
    POSITIONAL_ONLY: int = ...
    PARAM_SPEC: int = ...

求值规则用以下伪代码表示

def evaluate_callable_type(
    callable_type: ast.CallableType | ast.AsyncCallableType:
) -> CallableType:
    return CallableType(
       is_async=isinstance(callable_type, ast.AsyncCallableType),
       arguments=_evaluate_arguments(callable_type.arguments),
       return_type=evaluate_expression(callable_type.returns),
    )

def _evaluate_arguments(arguments):
    match arguments:
        case ast.AnyArguments():
            return Ellipsis
        case ast.ArgumentsList(posonlyargs):
            return tuple(
                _evaluate_arg(arg) for arg in args
            )
        case ast.ArgumentsListConcatenation(posonlyargs, param_spec):
            return tuple(
                *(evaluate_arg(arg) for arg in args),
                _evaluate_arg(arg=param_spec, kind=PARAM_SPEC)
            )
        if isinstance(arguments, Any
    return Ellipsis

def _evaluate_arg(arg, kind=POSITIONAL_ONLY):
    return CallableTypeArgument(
        kind=POSITIONAL_ONLY,
        annotation=evaluate_expression(value)
    )

向后兼容的 API

为了与现有的 `types.Callable` API 向后兼容，该 API 依赖于 `__args__` 和 `__parameters__` 字段，我们可以将它们定义为就像是用以下方式编写的

import itertools
import typing

def get_args(t: CallableType) -> tuple[object]:
    return_type_arg = (
        typing.Awaitable[t.return_type]
        if t.is_async
        else t.return_type
    )
    arguments = t.arguments
    if isinstance(arguments, Ellipsis):
        argument_args = (Ellipsis,)
    else:
        argument_args = (arg.annotation for arg in arguments)
    return (
        *arguments_args,
        return_type_arg
    )

def get_parameters(t: CallableType) -> tuple[object]:
    out = []
    for arg in get_args(t):
        if isinstance(arg, typing.ParamSpec):
            out.append(t)
        else:
            out.extend(arg.__parameters__)
    return tuple(out)

types.CallableType 的附加行为

正如 PEP 604 中引入的并集类型的 A | B 语法一样

• `__eq__` 方法应将等效的 `typing.Callable` 值视为等于使用内置语法构造的值，否则应表现得像 `typing.Callable` 的 `__eq__`。
• `__repr__` 方法应生成一个箭头语法表示，该表示在求值时将返回一个等效的 `types.CallableType` 实例。

函数即类型

我们很早就考虑过的一种想法是 允许使用函数作为类型。这个想法是允许函数代表其自身的调用签名，其语义与回调协议的 __call__ 方法大致相同。

def CallableType(
    positional_only: int,
    /,
    named: str,
    *args: float,
    keyword_only: int = ...,
    **kwargs: str
) -> bool: ...

f: CallableType = ...
f(5, 6.6, 6.7, named=6, x="hello", y="world")  # typechecks as bool

这可能是一个好主意，但我们不认为它是可行的可调用类型替代方案。

• 处理 ParamSpec 会很困难，而我们认为这是支持的关键功能。
• 当使用函数作为类型时，可调用类型不是一等值。相反，它们需要一个单独的、离行的函数定义来定义类型别名。
• 它不会比回调协议支持更多功能，而且似乎更像是编写它们的一种简写方式，而不是 Callable 的替代品。

混合关键字-箭头语法

在 Rust 语言中，关键字 fn 用来表示函数，这与 Python 的 def 类似，而可调用类型则用混合箭头语法 Fn(i64, String) -> bool 表示。

我们可以使用 `def` 关键字来表示 Python 中的可调用类型，例如，我们的两个参数布尔函数可以写成 def(int, str) -> bool。但我们认为这可能会让读者误认为 def(A, B) -> C 是一个 lambda，特别是因为 JavaScript 的 function 关键字用于命名函数和匿名函数。

无括号语法

我们考虑过一种无括号语法，它会更简洁

int, str -> bool

我们反对它，因为这在视觉上与现有的函数头语法不那么相似。此外，它在视觉上与 lambda 相似，lambda 使用无括号来绑定名称：lambda x, y: x == y。

要求外部括号

当前提案的一个担忧是可读性，尤其是在返回类型位置使用可调用类型时，这会导致多个顶层 `->` 标记，例如

def make_adder() -> (int) -> int:
    return lambda x: x + 1

我们考虑过一些想法来改变括号规则以防止这种情况。一种是将括号移到外面，这样两个参数的布尔函数就写成 (int, str -> bool)。通过这种更改，上面的示例变成

def make_adder() -> (int -> int):
    return lambda x: x + 1

这使得许多难以理解的嵌套示例变得清晰，但我们拒绝了它，因为

• 目前在 Python 中，逗号的绑定非常松散，这意味着人们可能经常误读 (int, str -> bool) 为一个第一个元素是 int 的元组，而不是一个两个参数的可调用类型。
• 它与函数头语法不太相似，而我们的目标之一是模仿函数头的熟悉语法。
• 这种语法对于深度嵌套的可调用类型可能更易读，但深度嵌套并不常见。通过样式指南鼓励在返回位置的可调用类型使用额外的括号，可以获得大部分可读性优势，而不会带来缺点。

我们也考虑过要求在参数列表和外部都使用括号，例如 ((int, str) -> bool)。通过这种更改，上面的示例变成

def make_adder() -> ((int) -> int):
    return lambda x: x + 1

我们拒绝了这个更改，因为

• 外部括号仅在某些情况下有助于提高可读性，主要是在可调用类型用作返回注解时。在许多其他情况下，它们会损害可读性而不是帮助。
• 我们同意，在某些情况下鼓励使用外部括号可能是有益的，特别是对于函数返回注解中的可调用类型。但是
  • 我们认为，在样式指南、linter 和自动格式化程序中鼓励这一点比将其硬编码到解析器中并抛出语法错误更合适。
  • 此外，如果类型足够复杂以至于可读性是问题，我们总是可以使用类型别名，例如

    IntToIntFunction: (int) -> int
    
    def make_adder() -> IntToIntFunction:
        return lambda x: x + 1
    

使 → 绑定比 | 更紧密

为了允许在类型表达式中使用 `->` 和 `|` 标记，我们必须选择优先级。在当前提案中，这是一个返回可选布尔值的函数

(int, str) -> bool | None  # equivalent to (int, str) -> (bool | None)

我们曾考虑让 `->` 绑定得更紧密，以便表达式可以解析为 ((int, str) -> bool) | None。这有两个优点

• 这意味着我们不再需要将 None | (int, str) -> bool 视为语法错误。
• 查看今天的 typeshed，可选的可调用参数非常常见，因为使用 `None` 作为默认值是标准的 Python 惯用法。让 `->` 绑定得更紧密将使这些更容易编写。

我们因为几个原因决定不这样做

• 函数头 def f() -> int | None: ... 是合法的，表示一个返回可选 int 的函数。为了与函数头保持一致，可调用类型也应该如此。
• TypeScript 是我们所知的另一个使用 `->` 和 `|` 标记的流行语言，它们在类型表达式中，并且它们让 `|` 绑定得更紧密。虽然我们不必效仿，但我们倾向于这样做。
• 我们确实承认可选的可调用类型很常见，并且让 `|` 绑定得更紧密会强制使用额外的括号，这使得这些类型更难编写。但代码的阅读次数比编写次数多，我们认为对于像 ((int, str) -> bool) | None 这样的可选可调用类型，要求使用外部括号更有利于可读性。

引入类型字符串

另一个想法是添加一种新的“特殊字符串”语法，并将类型放在其中，例如 t”(int, str) -> bool”。我们拒绝了它，因为它的可读性不高，并且似乎与 Python 核心开发者委员会关于确保类型表达式不偏离 Python 其他语法 的指导方针不符。

提高索引可调用类型的可用性

如果我们不想为可调用类型添加新语法，我们可以考虑如何使现有类型更易于阅读。一个提案是使内置的 `callable` 函数可索引化，以便它可以用作类型

callable[[int, str], bool]

此更改类似于 PEP 585，它使得像 `list` 和 `dict` 这样的内置集合可以用作类型，并且将使导入更方便，但它对类型本身的可读性帮助不大。

为了减少复杂可调用类型所需的括号数量，可以使用元组来表示参数列表

callable[(int, str), bool]

这实际上是多参数函数可读性的一项重大改进，但问题在于它使得具有单个参数（这是最常见的参数数量）的可调用类型难以编写：因为 (x) 被评估为 x，它们必须写成 callable[(int,), bool]。我们觉得这很别扭。

此外，这些想法都没有像当前提案那样在减少冗长性方面提供多少帮助，也没有像参数类型和返回类型之间的 `->` 那样引入强大的视觉提示。

替代 API

我们考虑过让运行时数据 `types.CallableType` 使用更结构化的 API，其中会有单独的字段用于 `posonlyargs` 和 `param_spec`。当前提案受到 `inspect.Signature` 类型的启发。

我们在字段和类型名称中使用“参数”（argument），而不是像 `inspect.Signature` 那样的“参数”（parameter），以避免与遗留 API 中指代类型参数而不是可调用参数的 `callable_type.__parameters__` 字段混淆。

在 __args__ 中使用纯返回类型表示异步类型

关于我们是否需要保留 `__args__` 对于异步可调用类型（如 async (int) -> str）的向后兼容性，这一点是可以争论的。原因是有人可能认为它们不能直接通过 `typing.Callable` 来表达，因此将 `__args__` 设置为 (int, int) 而不是 (int, typing.Awaitable[int]) 是可以的。

但我们认为这将是成问题的。通过保留向后兼容 API 的外观，但实际上破坏了异步类型的语义，我们将导致试图使用 `__args__` 来解释 `Callable` 的运行时类型库静默失败。

正是出于这个原因，我们自动将返回类型包装在 `Awaitable` 中。