如何看待Python中加入static typing?
程序员文章站
2022-04-22 13:12:38
...
在twiter上关注蟒爹(Guido van Rossum)的.
蟒爹好像最近一直在搞static typing.
http://pan.baidu.com/s/1cFROXS (最近的一个ppt)
blog上也突然多了http://neopythonic.blogspot.com/
然而对于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行。 那些个时髦语言不过是暂时裸体而已，等把程序员勾引到手了，最后会把脱掉的衣服一件件穿回去 喜闻乐见，代码更好读了。。。
蟒爹好像最近一直在搞static typing.
http://pan.baidu.com/s/1cFROXS (最近的一个ppt)
blog上也突然多了http://neopythonic.blogspot.com/
回复内容：
不是为了 linter 做的 annotation 么 2016年5月31日更新，Guido对于解决循环引用的方法if False:
from a import A
class B:
def compare(self, a: 'A')
然而对于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行。 那些个时髦语言不过是暂时裸体而已，等把程序员勾引到手了，最后会把脱掉的衣服一件件穿回去 喜闻乐见，代码更好读了。。。
声明：本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系admin@php.cn核实处理。
相关文章
相关视频
上一篇： 正则匹配中文有关问题