为什么没有类似 TypeScript 这样的 TypePython 语言（ Python 超集）呢？

• 資深大佬 : mxT52CRuqR6o5

  python3

• 資深大佬 : cmdOptionKana

  看 facebook 出品的这个

  https://pyre-check.org
  https://github.com/facebook/pyre-check

• 資深大佬 : ciaoly

  Python 创始人不是去微软了？你要的 type Python 大概在路上了

• 資深大佬 : tabris17

  cython

  stackless python

• 資深大佬 : cmdOptionKana

  其实像 python, ruby 这样的动态语言，从理念上说是比静态语言更先进的，曾经也凭效率和优雅火过一把，当时还有句名言 “编程语言发展的终极形态就是 Lisp”，当时认为电脑性能提升了，动态语言运行效率问题变得不重要，反而写程序写得快更重要，然而……

  没想到的是，IDEA 、Atom 、vscode 等现代化 IDE/编辑器的发展，让静态语言写起来也很快，静态分析功能也强大，反而动态语言傻了眼，风水轮流转，静态语言又全面制霸了。

• 資深大佬 : wlnirvana

  从另一个侧面来看，也是因为 Web 技术过去十几年实在是太火了，发展远远超过 Python，所以大公司愿意在相关的工具链上投入大量资源和精力，才有了 TypeScript 这种东西。

• 資深大佬 : seki

  因为 python 本身就设计有 typing
  https://docs.python.org/3/library/typing.html

• 資深大佬 : xiaolinjia

  python3 有 type hints，只是因为不兼容 py2，被一些人狂吐槽罢了。实际上 py3.6+ 的很多第三方库，都已经加上 type hints 了。https://www.v2ex.com/t/669912#reply46

• 資深大佬 : MinQ

  IronPyton 坟头草都快 2 米高了

• 資深大佬 : vincenttone

  如果你只是为了规范，python 完全可以规范了，还要个超集做规范是要干什么。。。毕竟 python 不是 js

• 資深大佬 : no1xsyzy

  Python 还有不少库实用上了 __annotations__
  比如 dacite 和 pydantic
  似乎站里有人自称做过一个把函数根据 __annotations__ 自动生成图形界面的

• 資深大佬 : owtotwo

  平时 Python 代码过百行基本都写满 type-hints 的
  pyright 挺好用的 不喜欢也可以换 mypy 或者其他

• 資深大佬 : laike9m

  TypeScript 和 Python 用户路过。从使用体验来讲，type hints 远远好于 TypeScript，主要在于 TypeScript 的许多生态和 JavaScript 割裂严重，尤其是工具链。如果说 Js 今天就从世界上消失那其实问题不大，但我总有种 TypeScript 和 JavaScript 往后会变成 Python 2/3 之争的感觉。

• 資深大佬 : Mark24

  @cmdOptionKana 还是人工工资太便宜，有个成本导向。

• 資深大佬 : ruanimal

  @xiaolinjia python2 坟头草也 1 米高了

• 資深大佬 : wellsc

  Cython?

• 資深大佬 : est

  你们想要的不是 type，你们想要的是 IDE 里 . 一下自动弹提示和属性方法写错了的自动检查。

• 資深大佬 : Macv1994

  @ruanimal 一米高应该还差 1 个月 13 天 哈哈哈

• 資深大佬 : crella

  @cmdOptionKana Visual Studio 2010 的功能已经比较强大了吧，我恨我自己作为外行人士，竟然太晚学习 C#，明明一开始就是从 VB6 转 VB.NET 的。

• 資深大佬 : szzhiyang

  @est 没有 type 就没有后者。

• 資深大佬 : jatai

  随着廖雪峰入职微软, 这个很快就会有了, 不过应该不影响 游标卡尺 热卖现状

• 資深大佬 : nthhdy

  有 mypy 啊，正是你想要的

• 資深大佬 : lewinlan

  为什么会有 ts ？ 因为你不能决定客户端用什么，所以必须兼容 js 。
  那么问题来了，为什么在你可以主宰一切的后端，还要委屈自己强行给 python 加类型？
  直接静态类型语言吧
  人生苦短，少点动态

• 資深大佬 : l1nyanm1ng

  @jatai 过分了啊，你甚至不肯称呼廖雪峰大神一声教父（狗头保命

• 資深大佬 : xfcy

  Tython 好像听起来也不错

• 資深大佬 : Roxk

  @xfcy 中文名：泰森

• 資深大佬 : est

  @cmdOptionKana 静态语言的最终归属就是一大堆 XML 来实现动态特性。

  哦不对，YAML 。。。
• 資深大佬 : AX5N

  python 这个所谓的 typing 丑到掉渣，与其让我这样写，我直接换静态语言算了。

• 資深大佬 : secondwtq

  #23 是正解，JS 这语言和政府一样，有天然的垄断性，所以其实很多时候是作为目标语言。但是 JS 从设计之初（如果这破玩意真的有“设计”的话）又是作为编程语言来设计的，所以 JS 有直接的编程语言和间接的目标语言两面（有意思的是，JS 无论作为编程语言，还是作为目标语言，都挺烂的 …）。
  前端圈开始是把 JS 作为编程语言来用，后来发掘出了目标语言的潜力，这才有了各种 source-to-source transformer，后来又有了各路 Script 。TypeScript 作为各路 Script 中的一个实例，虽然以兼容 JS 为核心设计理念，在作为“JS 的‘超集’的同时”依然可以理解为“以 JS 为目标语言的船新的编程语言”（忒修斯：阿嚏！）

  如果把目标定在 JS 上的话，那 Babel 则是一个静态的 Rosetta，Reason 相当于 ocamlopt，TypeScript 类似 C 语言。在 naive 领域，目标语言是具体 ISA 的机器码，CPython 实际上是“用 C 实现的一个脚本语言解释器”，从目标语言的角度来看已经可以和 TypeScript 有一定的可比性，所以说 CPython 汁己就已经是 TypeScript 了，同时还有对等的 Ruby 、Perl 和一些无 JIT 的 Scheme 实现等。（ CPython 放在 JS 上应该是“用 JS 实现的一个脚本语言解释器”——因为 JS 作为目标实在是太慢了，所以除了练手项目之外很少见，可以说前端在应用层“AOT 编译”占绝对主导）

  和 JS 有类似情况的语言其实不少，C 是最接近的之一，有很多 C 的”超集“，以及一些和 C 完全不同的编程语言是编译到 C 的，同时 C 也广泛作为通用编程语言使用。还有 JVM Bytecode/MSIL/LLVM IR 等，不过这些语言本身设计就是目标语言 /中间语言，并不能作为编程语言。

• 資深大佬 : Death

  @laike9m
  可惜 Reason 没有流行起来，就个人的体验而言，Reason 的 type system 感觉比 TypeScript 好多了。

• 資深大佬 : namelosw

  @laike9m Compatible 的, 怎么可能割裂

• 資深大佬 : namelosw

  @Death Hindley-Milner 从七十年代就已经成型了, 主要还是人们不思进取, 看见跟 C 不像的语言就敬而远之

• 資深大佬 : namelosw

  @cmdOptionKana 这两个不矛盾, 最终还可以有静态类型的 LISP, 已经有很多了, 其实 TypeScript 抄的就是 Typed Racket. 然后还有比如 Lux Lang 这种 ML module + Haskell type system + LISP syntax 的新语言.

  长远来讲肯定是静态语言更强, 前提是表现力足够强, 允许人们表达绝大多数能想到的程序. 像 Java C#这种抠脚的类型系统很多代码写不出来. 像 Haskell 都有很多程序写不出来, TypeScript 很多时候也不得不用 as any.

  最终方向就是 Lambda Cube 全满, 像 Idris 那种 Dependent Type 语言, 不过问题是想写好 IDE 还要等几十年.

• 資深大佬 : dustinth

  TypeScript 和 JS 是相辅相成的: JS 的广泛应用给 TypeScript 提供了用户基础, 也是 TypeScript 的在设计上定义为 JS 的超级以及采用类型抹除方案的原因; 反过来, JS 的动态特性以及 JS 的没有静态 Type System 的包袱也为 TypeScript 在 Pratical 的 Type System 上玩到极致提供了基础.

• 資深大佬 : oahebky

  其实你要的“编译”功能，不是“类型声明”。

  然后这个“编译”其实就是 “一键报‘低级’错误” ！

  其实其它编译型语言，写到“抽象”级别，类型声明一样没有啥帮助，错的跑起来 bug 的地方一样错，一样崩溃；一样在写代码的时候发现不了。

  ======

  当然，有编程语言本身带“编译报错”功能和不带编译报错功能是有区别的。

• 資深大佬 : learningman

  @xiaolinjia 我学 Python 的时候，这玩意儿就已经是标准了

• 資深大佬 : SingeeKing

  其实主要的就是 Pydantic 吧，参数类型不对直接报错，typing hint 最多算是强大一点的注释，运行时并不起作用

  另外，CPython 是 Python 的 C 实现，Cython 才是一种基于 C+Python 多东东，上面说的很多这个人概念是模糊的

• 資深大佬 : laike9m

  @namelosw 举几个例子。
  – js 里的 map 类型，ts 里就没有，因为 map 是后来加的。最接近的只能用 record，但也有一些问题
  https://stackoverflow.com/a/30019750
  – protobuf + grpc 的代码生成。grpc-js 至今无法依赖官方工具生成 ts binding，只能依靠第三方库
  – 各种各样的库都没有 ts 版本，或者有了也没有很好的支持

  这些问题我相信只要你写了一定量的代码都会遇到，并且在一个社区要支持两种语言的情况下是必然出现的。

• 資深大佬 : laike9m

  @SingeeKing 用静态语言不就是想在编译期检查出错误么，而不是放在运行时才报错么

• 資深大佬 : myCupOfTea

  typing hint 简单用用还行,其实还是有点鸡肋

• 資深大佬 : mepwang

  自己从头做一个新的编程语言，或者从现有 python 分支一个出来
  看不爽就自己搞出个新的来打倒它，这才是来源精神

• 資深大佬 : namelosw

  @laike9m 这些都是 checker 的事情啊，并不妨碍你用，可以 any，可以 allowJs. TS 不像其他的静态类型语言 check 不过就不能运行.

• 資深大佬 : halo117

  @namelosw 主要是这些概念超前的类型理论只要有好处一定会被现有 PL 至少在未来某天吸收并在某种特性延展开来，而不得过往一开始就标榜类型系统强大的语言身上得到繁华。 性能，代码复杂度维护，抽象表达能力三者从项目角度是不可能同时满足优势的三角，只能取其两两。现代软件工程里面只关注前两者居多，后者过于复杂是应该非常警惕，而且不可取

• 資深大佬 : namelosw

  @halo117 很多人都会下这种结论, 我倒觉得可疑… 比如 map filter 复杂吗? 其实用几天就会发现一点也不复杂. 我很久以前看到 90 年代的老帖子, 很多人觉得让大部分程序员理解 map filter 是不可能的事情. 60 年代 Turner 就已经就已经搞清楚了, SICP 里面也清楚地写着, 结果 2013 年左右才真正进入主流视野. 不仅 map filter, 只要用一用, 连 Promise 这种概念主流程序员都能理解了.

  Hindley-Milner 的类型系统比 TypeScript 和 Scala 容易理解得多, 人们不用只不过是因为它们长在技能树上的不同分支上罢了. 我只能理解成归根结底是人们思想闭塞, 不愿意接受不同的思想.

  我觉得 Paul Graham 的“Blub 语言”很好地解释了这个现象: 为了不伤害某些人的感情, 假设“Blub 语言”即某个平庸的主流语言. 当“Blub 程序员”往鄙视链下面看的时候, 就会觉得“连 X 功能都没有, 简直是辣鸡”. 当“Blub 程序员”往鄙视链上面看的时候, 因为他不能理解这些设计, 因为他只会以 Blub 的形式来思考, 只会觉得“这些功能很奇怪”或者“都是 Blub 功能的语法糖而已”.

  因为工业界充满了“Blub 程序员”, 所以有价值的 feature 都要等半个世纪才会 adopt. 很多“Blub 程序员”每天还会抱怨自己做了一段时间的项目都是屎山, 却不能意识到他们的工具早已 underkill 了.

  Blub 语言出处: http://www.paulgraham.com/avg.html