歡迎光臨
每天分享高質量文章

為什麼 Python 4.0 不會像 3.0 一樣?

導讀:當提出向後不兼容的更改時python-ideas的新手偶爾會提出“Python 4000”的概念,這些更改不給當前合法的Python3代碼提供明確的移植路徑。畢竟,我們允許Python 3.0進行這種更改,那麼為什麼我們不允許它用於Python 4.0呢?

作者:Nick Coghlan

譯者:OSC-協作翻譯

來源:開源中國(ID:oschina2013)

我現在已經聽過那麼多問題了(包括更關註的措辭“你做了一次大的向後兼容性突破,我怎麼知道你不會再這樣做了?”),我想我會在這裡記錄我的答案,所以我將來能夠將人們引回來。

01 現在對 Python 4.0 的預測是什麼?

我現在的預測就是Python 4.0只不過是“Python 3.9後的版本”。就是這樣。對語言來說沒有重大改變,沒有主要向後兼容突破——從Python 3.9到4.0應該就像從Python 3.3 到3.4(或者從2.6到2.7)。我甚至預測穩定的應用程式二進制接口(Application Binary Interface)(在PEP 384中首次定義一樣)會在這個過渡邊界上保留。

按照當前語言特性發佈的速度(大約每18個月)意味著我們可能會在2023年的某個時候看到Python 4.0,而不是看到Python 3.10。

02 那麼 Python 將如何繼續發展?

首先,Python 增強提議流程沒有任何變化 —— 仍然提出了後向兼容的更改,添加了新模塊(如 asyncio)和語言功能(如 yield from)以增強 Python 應用程式可用的功能。隨著時間的推移,Python 3 在預設情況下提供的功能方面繼續領先於 Python 2,即使 Python 2 用戶可以通過第三方模塊或 Python 3 的後端訪問同等功能。

在解釋器實現和擴展上競賽還將繼續探索增強Python的不同方法,包括PyPy對JIT編譯器生成和軟體事務儲存的探索,以及在科學和資料分析社區中對充分利用現代CPU和GPU所提供的矢量化計算能力的面向陣列編程的探索。與其他虛擬機運行時(如JVM和CLR)的集成也有望隨著時間的推移而改進,尤其是當Python在教育領域取得的進展可能使其作為嵌入式腳本語言在更多的應用程式的運行時的運行環境中更受歡迎。

對於向後不兼容的改動,PEP 387提供了在Python 2系列中使用多年的方法的合理概述,並且至今仍然適用:如果某個功能被識別為過於有問題,那麼它可能會被棄用並最終被移除。

然而,對開發和發佈過程進行了許多其他變更,這使得在Python 3系列中不太可能需要這些棄用。

  • 正如CPython核心開發團隊和Python Packaging Authority之間的協作,以及將pip安裝程式與Python 3.4+的捆綁所揭示的,越加註重的Python Package Index,在它們能足夠穩定適應相對較慢的語言更新周期之前,減少了將模塊添加到標準庫的壓力。

  • “臨時API”概念(在PEP 411中引入)使得可以在提供標準向後兼容性保證之前,對可能從更廣泛的反饋中受益的庫和API應用“穩定”期。

  • 很多累積的遺留行為確實在Python 3過渡中被清除了,而Python和標準庫的新增功能要求比Python 1.x和Python 2.x時期要嚴格得多。

  • “單一來源”Python 2/3庫和框架的廣泛開發強烈鼓勵在Python 3中使用“文件棄用”,即使功能被更新的,首選的替代品替換。在這些情況下,文件中會放置棄用通知,建議新代碼首選的方法,但不添加編程棄用警告。這允許現有代碼(包括支持Python 2和Python 3的代碼)保持不變(以犧牲新用戶為代價,在維護現有代碼庫的任務時可能需要稍微學習一些)

    03 從(多數是)英語到所有書面語言

    同樣值得註意的是,Python 3預計不會像它原來那樣具有破壞性。在Python 3中所有與之相關的向後不兼容的改動中,許多嚴重的遷移障礙可以放在PEP 3100的一個小基點上:

    • 使所有字串都是Unicode,並具有單獨的bytes()型別。新的字串型別將被稱為’str’。

    PEP 3100是Python 3變更的基地,它被認為是毫無爭議的,單獨的PEP是沒有必要的。這個特殊變化被認為是無爭議的原因是因為我們使用Python 2的經驗表明Web和GUI框架的作者是正確的:作為應用程式開發者明智地處理Unicode意味著確保所有文本資料從二進制轉換為盡可能接近於系統邊界,按照文本處理,然後轉換回二進制以用於輸出的目的。

    遺憾的是,Python 2並不鼓勵開發人員以這種方式編寫程式——它大大模糊了二進制和文本資料之間的界限,並使開發人員難以將兩者分開,更不用說在代碼中了。因此,Web和GUI框架作者必須告知他們的Python 2用戶“始終使用Unicode格式文本。如果不這樣做,你可能會在處理Unicode輸入時遇到晦澀難以處理的bug”。

    Python 3是不同的:它在“二進制域”和“文本域”之間實現了更大的隔離,使得編寫正常的應用程式代碼變得更加容易,同時使得編寫二進制及文本邊界不太清晰的系統中的代碼變得更加困難。我在其他地方更詳細地介紹了Python 2和Python 3之間文本模型的實際變動。

    Python 對 Unicode 支持的這場革命是發生在更大的計算文本操作遷移的背景下的,從僅支持英文的 ASCII(1963年正式定義),到“二進制資料+編碼宣告”的模型(包括 C/POSIX locale 和在20世紀八十年代後期引入的 Windows 代碼頁系統)的複雜性以及從最初的 16 位 Unicode 標準版本(1991年發佈)到相對全面的現代 Unicode 代碼點系統(1996年首次定義,每幾年發佈一個包含了新的主要更新的版本)

    為什麼要提這一點呢?因為這種切換到“預設情況下使用 Unicode”是對 Python3 中後向不兼容最具破壞性的,而不像其他改動(它們與語言本身相關性更高),它是文本資料表示和操作方式在更大行業廣泛變化的一小部分。

    隨著 Python 3 轉換清除了語言特定問題,與 Python 早期版本相比,新語言功能的進入門檻要高得多,而且正在進行的從“帶編碼的二進制資料”切換到用於文本建模的 Unicode 的規模都比其他行業更廣泛,我看不到任何需要 Python 3 樣式後向兼容性中斷和並行支持的更改。

    相反,我希望我們能夠在正常的變更管理流程中適應任何未來的語言演變,任何無法以這種方式處理的提案都會被否決,因為它會給社區和核心開發團隊帶來不可接受的高昂成本。

    關於作者:Nick Coghlan,是CPython的核心開發人員,也是Python Software Foundation的董事會成員。他是幾個公認的Python增強建議的作者或共同作者(包括PEP 343,它在Python 2.5中添加了with陳述句和背景關係管理器,PEP 453看到了與Python 3.4捆綁在一起的pip安裝程式),並且還接受了一些Guido van Rossum代表BDFL代表的PEP。

更多精彩


在公眾號後臺對話框輸入以下關鍵詞

查看更多優質內容!


PPT | 報告 | 讀書 | 書單

Python | 機器學習 | 深度學習 | 神經網絡

區塊鏈 | 揭秘 | 乾貨 | 數學

猜你想看

Q: 你覺得Python4.0會是什麼樣

歡迎留言與大家分享

覺得不錯,請把這篇文章分享給你的朋友

轉載 / 投稿請聯繫:[email protected]

更多精彩,請在後臺點擊“歷史文章”查看

赞(0)

分享創造快樂