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 中，一个简单的加法函数看起来像这样

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

我们决定这样做有令人信服的理由

• (...) -> bool 的语义不同于任何有效类型 T 的 (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 会很困难，而我们认为 ParamSpec 是一个必须支持的关键功能。
• 当使用函数作为类型时，可调用类型不是一等公民。相反，它们需要一个单独的、独立于行的函数定义来定义类型别名。
• 它不会比回调协议支持更多功能，而且看起来更像是回调协议的简短写法，而不是 Callable 的替代品。

混合关键字-箭头语法

在 Rust 语言中，关键字 fn 用于指示函数，就像 Python 中的 def 一样，而可调用类型则使用混合箭头语法 Fn(i64, String) -> bool 表示。

我们可以在 Python 的可调用类型中使用 def 关键字，例如，我们的两个参数布尔函数可以写成 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, 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: ... 是合法的，表示一个返回可选整数的函数。为了与函数头保持一致，可调用类型也应该这样做。
• TypeScript 是我们知道的另一个在类型表达式中同时使用 -> 和 | 标记的流行语言，他们让 | 绑定得更紧密。虽然我们不必效仿他们的做法，但我们更倾向于这样做。
• 我们确实承认可选的可调用类型很常见，并且让 | 绑定更紧密会导致额外的括号，这使得这些类型更难编写。但是代码比编写更常被阅读，我们认为对于像 ((int, str) -> bool) | None 这样的可选可调用类型，要求使用外层括号更有利于可读性。

引入类型字符串

另一个想法是添加一个新的“特殊字符串”语法，并将类型放在其中，例如 t”(int, str) -> bool”。我们拒绝了这个想法，因为它不那么易读，并且似乎与 指导 不一致，指导来自指导委员会，要求类型表达式不偏离 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 类型。

我们在字段和类型名称中使用“参数”，而不是像 inspect.Signature 中那样使用“参数”，以避免与来自旧 API 的 callable_type.__parameters__ 字段混淆，该字段指的是类型参数而不是可调用参数。

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

是否需要保留 __args__ 对异步可调用类型（如 async (int) -> str）的向后兼容性是值得商榷的。原因是有人可能会说，它们无法直接使用 typing.Callable 表达，因此将 __args__ 设置为 (int, int) 而不是 (int, typing.Awaitable[int]) 会很好。

但我们认为这将是有问题的。通过保留一个向后兼容 API 的外观，同时实际上破坏了其在异步类型上的语义，我们将导致尝试使用 __args__ 解释 Callable 的运行时类型库以静默的方式失败。

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