python 各个版本之间为何差距很大？

[rondo9]

python2.0和3.0对于除号和整除有很大差异，不知道开发者为何这样指定规则？

[introom]

因为开发者蛋疼。

不过从用户的角度来说，在3里，/是带浮点除法，//是去尾整除，写起来还是很方便的。
在Py2，用户得蛋疼得加个.0比方说3/2.0来得到浮点结果，对于变量还得来个类型转换比如3/float(hoge)菜行。

[Damnever]

https://www.python.org/dev/peps/pep-0238/

[Mark24]

把Python2中设计不合理的，在Python 3中改进，规范化，比如2中print “待打印字符串”，3中，print("带打印字符串")，就是print也是函数，按照道理，应该有括号。规范化，线性化，改善性能，把默认字符串国际化，等等。3的方向就是这样

[rootsir]

因为python不是商业化语言，所以肯定没有商业化语言稳定

[rootsir]

更新上会比较激进

[0bit]

@rootsir Python只是在2.x到3.x的跨大版本升级上比较激进。
实际上在同一代的升级，还是很谨慎的，一般API变更不大，兼容也很好做。

[tini31]

最受不了的就是print带括号，我会说我在python中写的最多的关键字就是print吗

[guoqiao]

@tini31 对, print 有了括号, 语法上是更一致了, 但是用起来太不方便了.

Python 让人喜爱的重要原因之一就是简单方便不迂腐.
而这个改变其实不符合 Python 的哲学.
迎合了处女座, 但给一个最常用的功能带来了语法不兼容, 真的是得不偿失.

[clino]

其实要是python 3 改一个地方,然后4改一个地方,这样过渡得会比较平滑容易被接受
不过作者估计看不下去想把自己之前的设计重构推翻

[lilydjwg]

各个版本差异大的应该是 Lua 和 Ruby 而不是 Python，因为 Python 只是 2.x 和 3.x 差异很大，2.x 内部以及 3.x 内部基本上都是向下兼容的。

Python 3 为了正确地支持 Unicode，不得不与 Python 2 不兼容。既然都不兼容了，不如趁此机会把 Python 2 那些不好的地方都改了。于是又弄出许多小的语法差异。

另外，Perl 5 和 Perl 6 的差异更大。

@tini31 你是不是应该用 logging 了？

@guoqiao 如果你说 print 函数打字多，那么大部分情况下是的。可是 print('loading...', end='', flush=True) 真的很棒呢～

为什么不符合 Python 的哲学呢？不符合哪一条？我看它倒是挺符合 Explicit is better than implicit. 以及 Special cases aren't special enough to break the rules.

[tini31]

@lilydjwg 只不过输出个字符串再专门 import logging ？，拜托我用python很多时候就是当脚本和交互式命令行用的，不是当java用的

[jimzhong]

3更优美了，2有一些反人类的设计，还有unicode问题

[yakczh]

python2的字符集编码跟php一样,读入字节码,需要手动转换
python3的字符集编码跟java一样,不管外部输入的什么编码,内部统一用unicode

[lilydjwg]

@tini31 会有很多单独的输出？我真没见过几乎满屏都是 print 的情况。交互式命令行下你可以 p=print，然后用 p(xxx)，如果 repr 的结果不好用的话。

[lilydjwg]

@yakczh Java 是 UTF16，不是 Unicode，对于 U+ffff 以上的字符会当成两个字符的。

[yakczh]

@lilydjwg utf8 utf16le utf16be都是unicode子集 统称unicode可以不查表很方便地互相转换 java class文件就是用utf8存储的,读入内存才用utf16 ,python生成的pyc字节码也一样

[zhicheng]

Python 3.x 里有很多设计是非常优秀的，即使不在项目中使用，也建议多了解一下，现在在 Python 2.7 中可以写出和 Python 3.x 完全兼容的代码，具体看一下 __future__ 。

[leavic]

同感2里面print不带括号太蛋疼了，lambda都用不了它，写c还要来回切脑子

[wbsdty331]

3里面Print强制带括号

[Shy07]

@lilydjwg 求不黑 Ruby，我记得 Ruby 2.0 发布的时候，Matz 在演讲为什么要升级到 2.0 时提到一条， 2.0 完全兼容以前的代码，然后台上台下会心一笑

[ryd994]

其实2.x又不是不维护了，你还可以用啊

[zonghua]

据说语法最健全完善的是c#？

[spacewander]

@lilydjwg
试过py3.4下能跑的脚本，在py3.2就报错了，仅仅是因为有一处字符串我用了u'xxx'这样的形式……
原本py3.2已经移除了u'str'这样的语法，但是到了py的下一个子版本，为了兼容py2.7又重新引入这一语法，于是就出现了这样喜闻乐见的现象：

py2.7 ok
py3.2 ouch
py3.4 ok again, wtf?

[yakczh]

语法最健全完善是ruby
java/python的面向对象都是混搭风格

[yakczh]

@spacewander 人生苦短就是这么来的

[znoodl]

因为python是脚本语言，设计的目的是为了解决问题在规范上没有花大功夫，后来的规范和兼容也是没有考虑周全

[lilydjwg]

@spacewander 是的。因为 3.4 向下兼容 3.2，但是 2 和 3 之间是互不兼容的。重新使用 u 前缀并没有多大的坏处（只是加了个前缀而已，并没有语义上的差异），但是能使迁移顺利一些，何乐而不为呢？

[lilydjwg]

@Shy07 可是每次 Ruby 小版本升级 Vim 都要打补丁的说！

[Shy07]

@lilydjwg 那是 Vim 的事，Ruby 升级除了 1.8 升 1.9 那次，其他时候都是升完直接跑的，但是说到底 1.8 到 1.9 语法也没有出现不兼容，只是因为 1.9 增加了字符编码，1.8 的代码需要加上 encoding 信息而已

[lilydjwg]

@Shy07 细节我不记得了，应该是 C API 不兼容，不然正常的嵌入代码不会报错的。

1.8 到 1.9 中文相关的程序容易出问题。

[Shy07]

@lilydjwg C API 涉及到 Ruby 的实现问题了，这个确实，我有个项目每次升级 Ruby 解释器都要修改 Ruby 头文件，但这个和 Ruby 本身语法没关系。编码问题加个“#encoding:utf-8”基本解决，同样也和本身语法没关系。

我所知道的语法不兼容，唯一一例就是 1.9 之后“case ... when ...”结构里“when”的后面不能再加冒号了。不过加冒号和 “if ... then ...”、“for ... in ...”一样，都是属于照顾其他语言的用法，不是 Ruby 推荐的用法，不支持也好。

翻一下 Ruby 的更新列表，你会发现 Ruby 在早期语法确定以后，后续版本更新里鲜有重大变化，2.0 的关键字参数，也是在兼容原来语法的基础上增加的。Ruby 的每次更新重点几乎都是 VM、GC，今后还会有并发，并发其实还是和 VM 相关。
怎么说，家家有本难念的经吧，Ruby 自由的语法加上元编程的特性，让 Ruby 创造 DSL 的能力独领风骚，所以 Ruby 的开发团队不需要去纠结 Ruby 的语法，你改多了反倒浪费了 Rubist 的创造力，注意力可以全部放在如何让 Ruby 跑更快上面就可以了。

其他语言则是反过来，在实现了一个强大的 VM 之后，如何让语法更完善、开发效率更高就变成了他们的纠结的事情。最明显的例子莫过于 JS，拍黄片弱爆了，JS 才是世界上最好的语言（认真状）。

[lilydjwg]

@Shy07 嗯我说的是 Ruby 的实现。语法因为我不写所以不清楚，感觉还好，就是库的不同版本之间的兼容性比 Python 还差的样子。

[slideclick]

人类的大多数领域，后来者总比前人聪明，因为可以看到前人走过的陷阱。所以cpp比java好。
而python3是语言的自我更新而不是java代替cpp，以不兼容python2为代价，把很多陷阱规避掉。比如2>'3'在p2下面是有值的，这是个陷阱。至于p3改动的那些，为什么那么改，不是一两句可以讨论清楚的，比如print改为函数，可以看pep-3105 https://www.python.org/dev/peps/pep-3105/