Python現在其實是「兩種語言」,用好了直接起飛!

【CSDN 編者按】有業界人士認為,如今的 Python 可以看作是 「擁有同一個名字的兩種非常相似的程式語言」。這兩種語言可以稱之為非類型化 Python 和類型化 Python。

原文地址:https://threeofwands.com/python-is-two-languages-now-and-thats-actually-great/

未經授權,禁止轉載!

作者 | Tin 譯者 | 鄧曉娟

出品 | CSDN(ID:CSDNnews)

眾所周知,Python 在 3.6+ 版本的時候就加入了對「類型提示」的支持。這些「類型提示」可以說是一種新的語法,用於聲明一個變數的類型。通過聲明變數的類型,編輯器和一些工具可以提供更好的支持。

但實際上,這個新的能力讓 Python 社區中出現了一個小的分裂:有些人對類型提示完全不感興趣,對於 Python 語言似乎進入到一個新的領域而有所防備;另一部分人對不斷發展的類型工具的潛力感到非常興奮,迫不及待地想要嘗試。而絕大多數人處於中間,並不完全清楚在哪裡、以及如何更好地使用「類型提示」。

有業界人士認為,如今的 Python 可以看作是 「擁有同一個名字的兩種非常相似的程式語言」。這兩種語言可以稱之為非類型化 Python 和類型化 Python。儘管這兩種語言共享著一個非常大的共同基礎,但他們在幫助開發者解決問題的方式上有著根本的不同。

業務邏輯程式碼和類型化 Python 更配

大家都知道,程式碼中有基礎設施程式碼和業務邏輯程式碼。那我們可以設想一種思考程式碼的模式:

  • 基礎設施程式碼是很強大的程式碼,它暴露出易於使用的接口,負責解決困難和棘手的問題,如與瀏覽器對話(Flask)與資料庫對話(Django ORM,SQLAlchemy),依賴注入框架(incant),序列化(cattrs)或定義類(attrs,dataclasses);

  • 業務邏輯程式碼是枯燥無味的,但它能讓你在日常工作中解決問題,完成任務和衝刺;

  • 基礎設施程式碼的重點是啟用和授權業務邏輯程式碼,業務邏輯程式碼為公司、使用者或任何使用你寫的東西的人提供實際價值;

  • 基礎設施程式碼是你正在使用的庫,業務邏輯程式碼是你編寫和部署的程式碼。

值得注意的是,這種思考程式碼的方式就像所有抽象一樣,是有漏洞的。你使用的一個庫可能是其他庫之間的一個簡單層,因此具有業務邏輯程式碼的所有特徵;如果你是一個典型的軟體開發者,那你的工作程式碼庫基本上都會有你為這個程式碼庫編寫的基礎設施程式碼。即便如此,如上的思考軟體的方式還是可以在大部分時候套用,便於我們理解程式碼的。

基礎設施程式碼通常不可能在內部進行完全的類型提示。至少 Python 的類型系統裡還不行,而且可能永遠都不會強大到足以支持像 cattrs 和 attrs 這樣的庫所需要的操作類型。非類型化 Python 的最大優勢之一,是可用的基礎結構程式碼可以提供驚人且強大的 API,所以,無論是從前還是現在,非類型化 Python 對基礎設施程式碼來說是非常友好的。而非類型化 Python 對於業務邏輯程式碼來說就不是很友好了,這就是為什麼許多軟體開發者經常抱怨基於 Python 的大型系統維護困難的原因。

業務邏輯程式碼通常比基礎程式碼結構簡單得多,而且現在有成百上千,甚至數百萬的程式碼庫都在以簡便的方式去使用 SQLAlchemy 或 Django。正因如此,業務邏輯程式碼和類型化的 Python 非常匹配:比如將整個類別的 Bug 從運行時間轉移到類型檢查時間,易於重構,這對一個健康的程式碼庫生命週期至關重要;還有強大的編輯器支持,包括自動完成和穩健地列出引用、良好的程式碼導航;以及減少對測試的需要,畢竟測試大大增加了需要編寫和維護的程式碼量。它是支持物件導向的,很多情況下使用物件導向程式設計會使得程式碼更加容易擴展,並且可維護性更高。

那麼,如何讓業務邏輯程式碼和類型化 Python 的結合發揮它的作用?

首先,我們需要基礎設施程式碼在內部不進行類型提示,而似乎在程式碼邊界提供類型的接口。這正是生態系統的發展方向,就像 SQLAlchemy 2.0 和新一代的網路框架(如 FastAPI)的案例一樣。另外,隨著 Python 類型系統的成熟,它將會使一類基礎設施程式碼完全類型化。

這對開發者來說是一件好事。試想一下,當你了解了類型化/未類型化的 Python 的其中一個之後,那麼你學習另一個就相對容易,至少相對於學習一種完全不同的語言要容易許多。而且學習它將大大增強開發者本身的能力。

類型化 Python 的出現是件好事

類型化 Python 的出現是件好事

有人可能要問了:有沒有一門既適合基礎設施程式碼、又能讓業務邏輯程式碼可擴展性/可維護性更高的程式碼?雖然不敢斷言,但業內人士表示,對於 Python 這樣的語言來說幾乎是不可能的。可以參考下其他語言的情況:

  • JavaScript 似乎也有與 TypeScript 分裂的情況,相對於 infra 與業務邏輯程式碼。應該和 Python 的情況差不多;

  • Java 可以算是一種徹頭徹尾的業務邏輯語言,這就很好地解釋了它在業界的受歡迎程度,但所有的庫的接口都比較拉跨。基本可以認為 Java 實際上也是兩種語言,只不過基礎設施 Java 非常難操作。這就是為什麼如果一個人說他用 Python 寫了一個 ORM,大家可能會很興奮地想要去看看;但如果一個人說他用 Java 寫了一個 ORM,很多人可能會用看瘋子一樣看著他們;

  • Rust 在處理基礎設施程式碼方面,有一個非常有趣的方法,它們有強大的宏系統。可以把 Rust 宏看成是 Rust 上的一種不同的基礎設施語言。可以說,它融入(類型化)Rust 的方式特別優雅。

總地來說,類型化 Python 的出現對於社區來說是件好事,而非類型化 Python 也不會消失。我們只需要了解每種類型的正確定位,並努力地將它們有效地結合起來,就可以更好地為我們所用。

相關文章

最強 AI ChatGPT 真要取代程式設計師?

最強 AI ChatGPT 真要取代程式設計師?

【CSDN 編者按】ChatGPT 一出,「程式設計師要失業了」、「程式設計師要下崗了」之聲不絕於耳,引得程式設計師們不由得一陣驚慌,最強 ...

Python 真的很糟糕嗎?

Python 真的很糟糕嗎?

隨著 AI 的發展,憑藉易學易用的語法、豐富的庫和框架,Python 在機器學習、深度學習、自然語言處理和資料科學等領域有著廣泛的應用。然而...

Python 與 JavaScript 做比較公平嗎?

Python 與 JavaScript 做比較公平嗎?

在討論應該使用 Python 還是 JavaScript 構建項目時,一般我們都不會說只使用一種程式語言來構建所有的元件。 在現代軟體開發中...

Python 雖已登峰,但尚未造極!

Python 雖已登峰,但尚未造極!

本文來自 CSDN 策劃的《2022 年技術年度盤點》欄目。本欄目將圍繞程式語言、開源、雲端運算、人工智慧、架構服務、資料庫、晶片、開發工具...

如何減輕 Python 打包之痛

如何減輕 Python 打包之痛

本文主要介紹 Python 包管理的問題和解決方法,以及在安裝和運行 Python 時應遵循的策略和步驟。 原文連結:https://www...