如何看待Python中加入statictyping?

if False:
    from a import A

class B:
    def compare(self, a: 'A')

按照官方的说法，Python永远不会变成static typing的，现在的新语法只是为了帮助IDE进行检查，真正运行的时候不会有限制 没有也能用isinstance和assert实现同样效果。有了只是省点事而已。

然而对于python一大堆弱接口（不使用继承而是实现函数就算实现接口），并没有什么卵用，还是得用hasattr和assert。 这么说吧，目前已采用的PEP中，只有484说你该如何做类型标注，却没有任何一条PEP提及解释器将如何做类型检查，因为现在的解释器就是很单纯的不做类型检查。

蟒爹折腾了好久的mypy以及此次PyCon上表示说要把类型检查机制（不是type hint）提到PEP去。当然，纳入之后谁来管、如何实现、会不会有所改动，目前尚未可知。虽然py作为纯粹的解释型动态类型语言，不会给你真折腾个编译期来满足静态类型检查的要求，但是至少之后的某个版本Py中可能会给你真正统一的类型检查方式，可能是装饰器，可能是运行参数，但不管怎么样，不再是满世界assert。（甚至还捞出来个重载装饰器……）

这有何意义？一来写着方便了，不再需要你对每个参数都来个assert来保证类型可用；二来虽然没有编译期，但做做test还是不错的；此外还有JIT，pypy表示标注没卵用，因为标注并不能真正起到限制作用，但若有统一标准限制方法，起码就不再是没卵用了，可以看看Pyston（Pyjion不太了解）还是希望能够有这么个类型检查的。

当然，这个类型检查不会像Java/C/C++那样堪当重任，能在执行前给你保证没有类型错误（说到底以上语言照样不能给你搞定如溢出越界之类的运行时错误），说到底还是压根没有编译期。我TS用的不多，只上手写过几个小玩意，不知贵TS在编译为js过程中的类型检查究竟强大到何种地步，是不是连导入个原生js写的玩意它也能给配上类型检查，若是能，为何py不可以？若是不能，提入标准来鼓励社区进行转化难道不是个合理有效的办法？

——————————说早就有了的人一定看都没看那个ppt……

——————————
人家说的不是484弱爆了的hint，而是说在hint的基础之上实现真正的类型检查，在运行时进行限制，以及在非运行时进行推导，不是那个拿来当lint的玩意儿。

人家不是说的type sig，而是解释器级的static type，对，就是你们念叨的TypeScript式的类型检查机制。

貌似已经提交新的pep了（pep index里貌似没找到…）。不过放到pep里，就不一定是蟒爹说了算了……

———————————
可以看到的milestone是不错的，之后的提及更快的检查机制等都还值得期待，尽管目前用cpython仍就需要自己包个装饰器之类来实现检查。

TS的类型检查是在编译时，同样直观TS部分，不鸟非TS部分；如果Py的Static type特性有朝一日可以真并入CPython从解释器角度加入，首先至少能给JIT提供足够的便利。

唯一的问题只剩下，其实绝大多数Py模块都没有做过类型检查……

——————
喜大普奔！喜闻乐见！

然而蟒爹也管不住神一样不正常的PSF，啥时候能用上那只有天知道了。

等弄完静态类型，咱大概终于可以考虑一下把JIT纳入官养CPython了？ 当然好，最近写惯了swift，已经离不开静态类型了 关注mypy的时候觉得走错了路，类型推导不应该走解释器兼容的路，不然搞得hinting的语法很诡异，而且用的时候也会因为解释器的原因出现一些问题。

我觉得应该走typescript那样预编译产生无类型代码的路，既然官方也认为不应该在运行时加入类型限制，那么typing就不用考虑语法上兼容 我当然是资呲!
最近在移植一个python写的MYO开源协议到c++上，里面的类型乱的我都想*#&。
以及，struct 的pack unpack真好用，真良心，很大程度上说明了类型，但是移植到cpp还是要靠人肉。
最后，感谢std::function,std::bind,brace-initialization ,typedef,using,auto,shared_ptr做的一些微小的工作，1000行的python移植到c++竟然才1500行。 那些个时髦语言不过是暂时裸体而已，等把程序员勾引到手了，最后会把脱掉的衣服一件件穿回去 喜闻乐见，代码更好读了。。。