正如您所提到的，相关的PEP是3107（如果遇到其他问题的人尚未阅读，请链接以方便参考）。
目前，注释是一种实验，正在进行中。实际上，有关该主题的python-
ideas邮件列表中最近有一个主题，可能会有所帮助。（提供的链接仅用于每月存档；我发现特定帖子的URL倾向于定期更改。所讨论的线程在12月初附近，标题为“函数注释的[Python-
ideas]约定”。）第一篇文章来自12月1日的Thomas Kluyver。）
以下是Guido van Rossum在该主题中发表的一篇文章：
在2012年12月4日上午11:43，贾斯珀·圣·皮埃尔（Jasper St.
确实。我以前看过注解，但是我从不理解目的。这似乎是一项设计和实现的功能，没有考虑到任何目标，而且社区应该自行发现目标。
Guido的回应：
相反的。有太多用例立即显得很重要，而我们无法弄清哪个用例最重要或如何将它们组合在一起，因此我们决定采用两步法：在步骤1中，我们设计了语法，而在步骤2中，我们将设计语义。这个想法非常明确，一旦确定了语法，人们将可以自由地尝试不同的语义-
只是不在stdlib中。想法也是最终，从所有这些实验中，将出现一个适合于stdlib的实验。
贾斯珀·圣皮埃尔：
因此，如果我要问的话，注释的最初目标是什么？PEP提供了一些建议，但没有任何具体说明。它是否旨在辅助IDE或检查源代码的静态分析工具？应用程序本身需要通过某些方式来提供特殊行为，例如命令行解析器或运行时静态检查器吗？
Guido的回应：
几乎在某种程度上，以上所有方面。但对我个人而言，主要目标始终是得出一种符号，以指定参数约束和返回值的类型约束（可能还有其他约束）。我在各个时间都在用特定的组合类型方式戏弄。例如list
[int]可能表示整数列表，而dict [str，tuple
[float，float，float，bool]]可能意味着将字符串映射到三个浮点数和bool的元组的dict。但是我觉得，就这样一种符号达成共识要比对参数注释的语法要困难得多（想想您可以对这两个示例提出多少反对意见：-）-我一直强烈希望使用“
var：type = default”，并使类型成为要与默认值同时求值的运行时表达式。
和Ned Batchelder的一点幽默：
对我来说，一个很有意义的时刻是在PyCon上的Py3k早期主题演讲期间（也许是在达拉斯或芝加哥？），Guido记不清“
annotation”一词，并说：“您知道，那些不是类型声明的东西？:-)
