最近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 轉變為函數。看看這個文法：
print >> outfile, arg1, arg2
反對匿名使用者的說法，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 之間的「緩衝」，這項遷移並沒有造成很嚴重的問題。
