如何评价 Python 3 打破向后兼容（Backward Compatibility）的决定？

最近Hacker News上面的讨论：
https://news.ycombinator.com/item?id=6985207
https://news.ycombinator.com/item?id=7799524

从评论来看，社区的意见非常的两级分化。有人认为Python 3的新特性值得肯定；也有一大份部分人觉得Python 3带来的新特性不足以促使程序员进行迁移，打破向后兼容性更是一个败招，增大了移植的成本，有些dev索性直接转向其他语言，如Go和Node.js。

那么，为什么Python 3从设计开始之初会做出打破向后兼容性的决定呢？是因为开发者个人的好恶，还是为了有设计上跟深层次的原因不得不做出取舍？历史上有其他语言在打破了向后兼容性的情况下，依然得到平稳过渡的么？如果有，他们是如何做到的呢？

回复内容：

Python 3 作出的不兼容改动，我觉得对这门语言是有很大益处的。修正的地方其实是以前的设计失误， 下面举两个最明显的例子。
首先是print由 statement 转变为函数。看看这个语法：

<code class="language-text">print >> outfile, arg1, arg2
</code>

反对匿名用户的说法，Py3并不是开发者个人好恶影响~~~相反，我认为，Py3的升级，用「涅槃」二字形容，再合适不过。

话从头说起就很长，我也不善此道，简述之。

很久以前，Python只是一门脚本语言，地位类似于Perl，甚至shell、awk、sed之类，你看py2里面的反引号``（像极了Perl里的反引号），及其虚拟机的构造（大循环，无JIT）可窥一二，一般意义上人们认为「脚本语言」是「游击队」，不堪大用。

后来Python社区经营多年，终见起色，在GUI开发、Web开发、乃至于近些年的大数据等领域，开始有了一些与传统「正规军」编程语言（各方面对比Java）一搏高下的资本，于是有为其「正名」想法的人越来越多，也越来越理所应当。

python想向「正规军」发展，几个困扰其发展的根本性问题亟待解决，如JIT、Sandbox、GIL等，此外，更需要戒除一些「游击队」时养成的不良习惯，大致有以下问题：

popen2，甚至是popen3这种命名方式，至于为什么popen2这种命名不行，可百度 「史上最糟糕的两个变量名」
print语句问题，「正规军」里头，print可不能是关键字，这太掉价了
Threading.Thread这种与其他标准库命名风格不一的模块，大致参考PEP8，阉掉不符合规定的
unicode问题，str与byte混用的问题，得向java好生学学
「正规军」怎么能连个像样点的sandbox都不提供呢（虽然py3也没提供）~
......

由于需要解决的问题实在是太多，而有些问题（如JIT）则无可避免需要「伤筋动骨」（虚拟机乃至字节码格式需要改动），有些问题则无可避免需要破除向下兼容性（如蛋痛的模块命名修改后，原有代码无法运行），还有其他一些让编程更方便的东东如unicode/byte等，语法形式上的改动也破除了向下兼容性。

所以，要想有个更好的发展，必须跟过去来个了断，长痛不如短痛，所以，还是推到重来吧。 正好这两天在读Python的历史－Python创建者在blogspot上面写的博客，看到这个问题正好说说自己的想法。先回答问题：
首先是人就会犯错，人的认知也会随着时间发展而变化。编程语言也要发展，发展就不可能总是加法（C++试图这样发展）。Python的作者早就觉得Python里面有些东西没做对，有些东西没做好，为什么Python 3打破了后向兼容？没什么特别的，我们只是恰巧赶上了这时候，不是一时兴起，这事情背后有至少几年的思索了……
扯个远的，我好像听说90年代末期libc来了一次不向后兼容的更新，当时所有的应用程序都要重编才能适应新的libc。我相信当时的程序员心里也是一万头草泥奔腾而过……
然后打破后向兼容性和平稳过渡这两件事儿本来就是一矛盾，我觉得没人能做到，做到这个就好比是你刚学会韩语就希望全世界人跟着你学韩语。对于编程语言来说，打破兼容性还能平稳过渡的只有一种可能：这个语言没几个人在用……
如何评价这个事儿：这是个好事儿，但这不是个大事儿。它可能给我们带来一点儿困扰，但是2.7还在，你爱用哪个用哪个。
近一段时间了解了C++, Erlang, Go, Java, Haskell, Scheme, Scala, Ruby, Python等语言之后，突然想明白一件儿事：其实语言不重要。编程语言很有用，但不重要。前两天看到的一句话：“It is a lesson which all history teaches the wise, to put trust in ideas and not in circumstance.”，觉得用在取舍编程语言上也很有道理：不要信任（喜欢）那些语法的外衣，要对它们背后的想法保持信心！每一门语言背后都有独特的想法。Python 2到Python 3语法变了，但The Zen of Python没变，所以我依然挺它！
我觉得2到3的不兼容只不过是The Zen of Python在Python演进中的反应，例如下面几条：
There should be one-- and preferably only one --obvious way to do it.
If the implementation is easy to explain, it may be a good idea. 作为个人，我现在老老实实用 2.7，瞄着 3.x，估计这种状态可能会持续几年.
不介意有些东西用用 3.x 写，如果真的不需要什么依赖的话.
想要兼容还是有办法的，比如 https://pypi.python.org/pypi/six
至于抛弃后向兼容这种做法，似乎没对我造成什么影响（原因如上所述），这是应该的，改进了很多，反正自己水平太弱，写的东西跑不了几年，考虑那么多兼容性干嘛？ 谁都不想找蛋疼的！不兼容是权衡考虑以后的决断，我觉得这个决断是对的，可以成立的。

有的时候不是说想兼容就能兼容的，无限兼容就是无限的麻烦。

比如，windows 系统，至今你无法建立一个名字为 COM1 的文件夹。为什么？就是为了保持兼容性。具体历史原因可以去查资料。你觉得保持这样的兼容对于一个不断进步的操作系统来说是好是坏？

说的玄虚一点，哲学里有个词叫，扬弃，不抛弃旧的的东西就不能从根本上改变和进步。

其实嘛，我们都知道，设计protocol的时候一定要在数据里面带版本。其实如果语言也这样的话……

fuck.py:

import python2 // 我们可以规定python\d+不能作为用户自定义的模块的名字

blahblahblah

shit.py:

import python3

import fuck

blahblahblah

然后允许混用，但是一个py只能用一个版本，而且低版本的文件看不见高版本的符号，轻松愉快。

3比2没有本质性的性能提高（包括并发的支持），却有本质性的语法不兼容，自然不受欢迎了 据我所知，没有一个被广泛使用的语言在打破向后兼容性的情况下依然得到平稳过渡。

如果丧失了向后兼容，本质上你就是一个新的不同的语言，那么你自然无法完全的享受与迁移原有语言的资源。

C++ 语言的设计者最初的目的可是用来替代 C 的，可这么多年过去了，他也只是成为了与 C 平行的一种语言而已，没有办法取代 C。——这个意思是说，无论开发者有多么美好的愿景，一个已经广泛使用的语言很难被凭空废弃，如果坚持 python3 这种不兼容策略，那么后果将会是 python3 与 python2 发展成为两种不同的平行发展的语言。总会有一个团体始终不理睬 python3

Lua 其实是版本不向后兼容的典型。但这里有个问题，在 Lua 5.1 以前，Lua 并没有得到非常广泛的应用。Lua 大范围应用其实是在 Lua 5.1 时代，而这个 5.1 时代延续了非常长的时间。

现在 Lua 5.2 出现了，打破了向后兼容，但是绝大多数使用者仍然使用的 Lua 5.1 语法。他向 5.2 的迁移可能会是个漫长的过程。而兄弟项目 LuaJIT 更是宣布在可以预见的将来永远不会支持 5.2，一直坚持 5.1 语法的兼容性。这意味着 Lua 5.1 将在相当长的时间里继续存在为 Lua 的主流。而 5.2 成为了另外一种语言。

C 语言虽然这么多年发展过不少标准，但是没有打破过向后兼容性，非常老的代码用今天的编译器依然可以编译（极端的情况可能需要一些编译器选项）。这是一个非常典型的例证。

Python 打破向后兼容，当然纯粹是开发者的好恶。不然你认为呢？ 顺其自然吧……其实真的不用想太多，当年2.5上写出的程序在2.4上跑不了也是常有的，加个大版本号，有些变化太正常了。比比perl5到perl6，python2to3简直如丝般顺滑。 一楼的说法不完全正确。
有一个语言的演化过程里有打破兼容性，而且迁移的还算不错，它是 Fortran。
f90 规范里定义了一批「过时特性」（比如给老 IBM 机设计的 3 路 if），这些特性在 f95 里就给删了，不过因为有 f90 到 f95 之间的「缓冲」，这项迁移并没有造成很严重的问题。