正如您所提到的,相关的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”一词,并说:“您知道,那些不是类型声明的东西?:-)
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)