Python不能用於大型專案？人們對Python的十大誤解

Python 型別系統的特點是擁有強大、靈活的型別操作. 維基百科上對此作出的闡述.

而存在一個不爭而有趣的事實是， Python 是比Java更加強型別的. Java 對於原生型別和物件區分了型別系統，它讓null存在於一個灰色地帶. 另一方面，現代的 Python 擁有一個統一的強型別系統, 其中什麼都沒有（None） 的型別是明確指定的. 更進一步的，JVM自身也是動態型別的，因為可以把它的 根源 追溯到由Sun所收購的Smalltalk VM的一個實現.

Python的型別系統 很棒，但要提供給企業級使用，目前仍然還有許多更重大的事項需要關注.

歡迎加入群：725479218，技術分享，學習交流，資料共享

謬誤 #6: Python 速度慢

首先是有一個重要區別: Python 是一門程式語言，而不是執行時環境. Python 擁有幾個實現:

• CPython是參考實現, 且也是廣泛釋出和使用的實現.
• Jython是Python用於JVM的是一個成熟的實現.
• IronPython是 Microsoft 針對其自家的通用語言執行時——又名 .NET，實現的Python .

• PyPy是一個正在日趨成熟的Python實現，擁有JIT編譯，增量垃圾收集諸多先進的特性.
  每一個執行時都有其自己的效能特點, 而且他們本身也不慢. 這裡更重要的地方在於不能錯誤地把一個效能指標分派到一門程式語言智商. 應該總是把該評估用在一個應用程式執行時上面，最好是針對一個特定的使用場景.
  清楚了那些事項之後，下面就是一些有Python提供的小項，體現其重要的效能優勢:

• 把 NumPy 用作 Intel 的 MKL SIMD介面

• PyPy的 JIT 編譯能 達到比C還快的效能
• Disqus 能在同樣的100個盒子上容納兩億五千萬到5億使用者

誠然，這些都不是最新的列子，只是我個人的最愛罷了. 這將很容易扯到高效能Python以及獨立提供的執行時這些廣闊的領域. 我們不應只是專注於解決單個特殊的案例, 而是應該把注意力放在對開發人員在 最終產品效能 方面的生產力的普遍影響上面, 特別是在一種企業級環境之下.

C++ vs Python,. 兩種語言在同一個輸出下的對比.

給定足夠的時間，一個循規蹈矩的開發者只會按照下面這種經過論證的方式來編寫精確高效的軟體：

• 設計實現一個可以正確完成任務的軟體，包括開發單獨的測試
• 測試效能，明確瓶頸
• 優化，根據測試和Amdahl法則，並且利用Python與C的淵源
  雖然這聽起來很簡單，但是即使是老道的工程師，這依舊是一個非常耗時的過程。Python設計之初就考慮到了這一套開發流程。根據我們的經驗，通常C++和Java專案完成一次迭代流程的時間，夠Python專案完成三次迭代流程。今天，PayPal和eBay中不乏有Python專案使用更少的程式碼戰勝了同類C++和Java專案，這多虧了快速的開發使得仔細的裁剪和優化變得可能。

Myth #7: Python無法做到大規模

大規模有許多定義，但無論怎樣，YouTube是個大規模網站。每月UV超過十億，每分鐘上傳的視訊時長超過100小時，佔用網際網路頻寬的20%，所有這一切都以Python作為核心技術。Dropbox,Disqus, Eventbrite, Reddit, Twilio, Instagram, Yelp, EVE Online, Second Life,，以及，是的，以及eBay和PayPal中都有Python大規模的例子，這些證明大規模不僅僅是可能：它是一種模式。

成功的關是鍵簡單性且一致性。CPython，Python的主要虛擬機器，其最大限度地放大了這些特性，從而演變出了一個精確可測的執行時。人們很難發現 Python程式設計師關心垃圾的收集暫停或應用地啟動時間。擁有強大的平臺和網路支援，Python其本身自然而然的智慧水平可擴充套件，BitTorrent就是其充分的體現。

此外，規模化主要涵蓋測量和迭代。Python是以分析和優化為要義建立的。看Myth #6瞭解更多Python如何垂直擴充的細節。

Myth #8: Python缺少好的併發支援

除了偶爾叫囂效能和規模化的問題，有人想提的技術些，”Python缺乏併發，”或者，”GIL怎麼樣？”如果幾十個反例仍不足以支援Python水平及垂直擴充規模的能力，那麼再更深地解釋CPython實現細節也不會有幫助，所以我會簡短些。

Python擁有強大的併發原語，包括generators, greenlets, Deferreds, 和futures.。Python有優秀的併發框架，包括eventlet, gevent,和Twisted。Python在定製執行時尚投入了驚人的工作量，包括Stackless和 PyPy。所有煩人這些和更多表明，根本不存工程師們在Python併發程式設計方面的缺憾。同時，所有這些都正在被正式的在企業生產環境中支援或使用。例如，請參考Myth #7。

全域性直譯器鎖，或稱GIL，是Python在大多數應用場景下的效能優化，也是幾乎所有CPython實現程式碼的開發上的基礎優化。GIL使得Python可以很便利地使用作業系統的執行緒或輕執行緒（通常指greenlets），且不影響使用多程式。更多相關資訊，請看該主題的Q&A列表，以及Python文件中的介紹。

在PayPal中，一個典型服務的部署需要多臺機器，多個程式，多個執行緒，以及一個數字非常龐大的greenlets，相當於一個非常強大可擴充套件的並行環境（見下圖）。在大多數的企業環境中，團隊更傾向於往更高層次過度，謹慎並注重災難恢復。然而，在某些情況下，每臺機器每天Python服務仍然處理數以百萬計的請求，而且輕鬆處理。

一個基於單一worker的協同非同步架構草圖。最外層的盒子是程式，下一個層次為執行緒，這裡這些執行緒都是輕執行緒。作業系統處理執行緒間的搶佔，而I/O非同步協同合作。

謬誤 #9: Python 程式設計師很稀缺

事實上，現在使用 Python 的 web 開發者的確沒有使用 PHP 或者 Java 的 web 開發者多。這可能主要是由於企業需求和教育之間的相互作用導致的，不過 教育領域（教學所使用的程式語言）的趨勢使得情況可能產生變化 。

也就是說，使用 Python 的開發者並不稀缺。現在全世界有數百萬使用 Python 的開發者。已有幾十個Python 技術大會、 StackOverflow 上成千上萬的 Python 內容問答、僱傭大量使用 Python 的開發者的大企業比如 YouTube 、 美國銀行（ Bank of American ）和 LucasArts/Dreamworks 等等，這些都顯而易見地證實了這一點。在 eBay 和 PayPal 我們一直保持擁有幾百位使用 Python 的正式開發者，這是怎麼做到的呢？

那麼，當一個專案被建立時為什麼它會被首推？對於孩子來，大學生和教授們來說，Python作為第一門程式設計語言是非常易於學習的。在eBay，僅僅需要一個星期，一個新的Python程式設計師就能展示一個真正的成果，並且他們開始散發光芒常常只要2-3個月，通過Internet的寶藏（互動式教程，書，文件和開原始碼庫）一切皆有可能。

另外一個重要的考慮因素是，專案使用Python會更簡單，它不會像其他專案那樣需要那麼多的開發者。在謬誤6和謬誤9中提到的那樣，在Python專案中，學習像Instagram那樣的高效團隊是一個常見的比喻，並且這確實是我們在eBay和PayPal的經驗。

Myth #10: Python不適應於大專案

Myth #7 討論了大規模執行Python的專案，但開發Python大規模專案是什麼情況呢？正如在Myth #9中提到的，大多數Python不被人看好。 然而Instagram在其被億元美金收購當天達到千萬的點選量，而整個公司只有十幾個人。Dropbox在2011年只有70個工程師，其他團隊更少。所以，Python適合大規模團隊嗎？

美國銀行實際上有超過5000的Python開發者，一個單獨的專案超過一千萬行Python程式碼。JP摩根也經歷了類似的轉變。YouTube也有數千的開發者和數百萬行的程式碼。大規模產品和團隊每天都在使用Python，因為它具有良好的模組化和封裝特性，在特定方面許多的大規模開發建議是一致的。工具，強大的慣例以及程式碼審查促使了專案規模化管理的現實。

幸運的是，Python發展於上面所提到的好的奠基。我們在檢查執行使用pyflakes以及其他工具進行Python程式碼的靜態分析，正如堅持PEP8——Python語言的基礎風格指南。

最後，應該指出的是，除了排程加速Myth #6以及#7中所提到的，使用Python的專案通常需要更少的開發者。我們常見的成功案例中，使用Java或C++的專案通常有3-5開發者耗時2-6個月，最終由單一的開發者在2-6周（或小時，因為這些原因）完成專案。

有點像奇蹟，但卻是現代發展的事實，但其往往出自一個競爭激烈的行業。

一種乾淨的狀態

這些謬誤可能只是消遣。討論這些謬誤仍然很活躍的和受啟發的，包括內部和外部， 因為隱含在每一個謬誤裡的都是一個Python的優勢的認識。 而且， 記住這些看似乏味的表現和麻煩的問題是穩步成長的表露， 並穩定地增長興趣促進教育和持續地工作。 在這裡，希望能撲滅一場充滿火焰的戰爭，並且使得能真正去談論工作與Python的實現。

python學習交流群：725479218