python - Python 函数注解有什么用？

Question

这个问题在这里已经有了答案:

What are good uses for Python3's "Function Annotations"? (12 个回答)

关闭 9年前。

我已经阅读了 PEP 3107 中的前几个部分，但我仍然不明白它们对语言有什么好处。在我看来，您可以使用装饰器将元数据添加到函数中。例如

def returns(return_type):
  f.return_type = return_type  # <- adding metadata here
  return f

@returns(Foo)
def make_foo(): ...

您也可以将元数据添加到参数中，如果您利用默认参数，它看起来会很漂亮，如下所示:

import inspect

def defaults_are_actually_metadata(f):
  names, args_name, kwargs_name, defaults = inspect.getfuncspec(f)
  f.parameter_metadata = dict(zip(names[-len(defaults):], defaults))
  f.__defaults__ = ()
  return f

@defaults_are_actually_metadata
def haul(load="Stuff to be carried.",
         speed_mph="How fast to move the load (in miles per hour)."): ...

至少我最初的印象是注解是多余的:装饰器可以做所有注解可以做的事情(甚至更多)。在向函数添加元数据时，为什么注解比装饰器更好？

Answer 1

正如您所提到的，相关的 PEP 是 3107 (链接以便于引用，以防遇到此问题的其他人尚未阅读)。

目前，注释是一种实验，一种正在进行中的工作。 python-ideas mailing list 实际上有一个最近的线程关于可能有帮助的主题。 (提供的链接仅用于每月存档；我发现特定帖子的 URL 往往会定期更改。有问题的线程在 12 月初附近，标题为“[Python-ideas] 函数注释约定”。第一篇文章是 Thomas Kluyver 于 12 月 1 日发布的。)

以下是 Guido van Rossum 在该线程中的一篇帖子:

Jasper St. Pierre 于 2012 年 4 月 12 日上午 11:43 写道:

Indeed. I've looked at annotations before, but I never understood the purpose. It seemed like a feature that was designed and implemented without some goal in mind, and where the community was supposed to discover the goal themselves.

Guido 的回应:

To the contrary. There were too many use cases that immediately looked important, and we couldn't figure out which ones would be the most important or how to combine them, so we decided to take a two-step approach: in step 1, we designed the syntax, whereas in step 2, we would design the semantics. The idea was very clear that once the syntax was settled people would be free to experiment with different semantics -- just not in the stdlib. The idea was also that eventually, from all those experiments, one would emerge that would be fit for the stdlib.

贾斯珀·圣皮埃尔:

So, if I may ask, what was the original goal of annotations? The PEP gives some suggestions, but doesn't leave anything concrete. Was it designed to be an aid to IDEs, or static analysis tools that inspect source code? Something for applications themselves to munge through to provide special behaviors, like a command line parser, or runtime static checker?

Guido 的回应:

Pretty much all of the above to some extent. But for me personally, the main goal was always to arrive at a notation to specify type constraints (and maybe other constraints) for arguments and return values. I've toyed at various times with specific ways of combining types. E.g. list[int] might mean a list of integers, and dict[str, tuple[float, float, float, bool]] might mean a dict mapping strings to tuples of three floats and a bool. But I felt it was much harder to get consensus about such a notation than about the syntax for argument annotations (think about how many objections you can bring in to these two examples :-) -- I've always had a strong desire to use "var: type = default" and to make the type a runtime expression to be evaluated at the same time as the default.

还有一点来自 Ned Batchelder 的幽默:

A telling moment for me was during an early Py3k keynote at PyCon (perhaps it was in Dallas or Chicago?), Guido couldn't remember the word "annotation," and said, "you know, those things that aren't type declarations?" :-)