謬誤 #1: Python 是一門新語言
伴隨著所有的初創公司正在使用它以及孩子們最近也在學習它的事實，這個謬誤為何仍然存在是可以理解的。實際上 Python 已經 超過23歲了， 它最初發佈於1991年， 早於 HTTP 1。0協議 5年且早於 Java 4年。 目前比較有著名的很早就使用 Python 的例子是在1996年： Google 的第一個成功的網路爬蟲。
如果你對於長長的 Python 歷史比較好奇，Python 的作者 Guido van Rossum 已經為你準備好整個故事了。
謬誤 #2: Python 沒有被編譯
不像 C++ 一樣需要一個獨立的編譯器工具鏈，Python 實際上被編譯成了位元組碼，和 Java 或者許多其他的編譯型語言十分相似。更進一步的編譯過程，如果有的話， 取決於執行時環境， 不管是 CPython，PyPy，Jython/JVM，IronPython/CLR，或是其它的程序式虛擬機器（process virtual machine）。參考 謬誤 #6 來了解更多。
一條在 PayPal 以及其它地方的通用原則就是，（應用的）安全性不能依賴於程式碼的已編譯狀態。更為重要的是加強執行時環境的安全，因為實質上每種語言都有一個解碼器，或者能被攔截並匯出受保護的狀態。參考下一條謬誤來了解更多的 Python 安全性問題。
謬誤 #3: Python 不安全
輕量級 Python 的親和力可能使他看起來不怎麼可怕，但是這裡直覺很大程度上是受到了誤導的。 安全的一個核心原則就是儘可能讓呈現的目標更小。 大系統是違背安全原則的，因為他們趨向於 使行為過渡集中化， 並且也 讓開發者難於理解。 Python 透過倡導簡潔化來邊緣化這些噁心的問題。 更有甚者， CPython 透過讓自己成為一個簡單、穩定並且易於稽核的虛擬機器來使這些問題得到解決。 事實上，近期 Coverity Software 的一個分析結果顯示 CPython 得到了他們的最高質量評級。
Python 還擁有一系列可擴充套件的開源、產業標準化的安全庫序列。 在PayPal， 我們把安全和授信看做是重中之重， 我們發現 hashlib， PyCrypto， 以及 OpenSSL， 透過 PyOpenSSL 和我們自己的定製構建的結合，涵蓋了 PayPal 多樣化的安全和效能需求。
這些諸多的原因，使得 Python 成為PayPal（和eBay）的應用程式安全團隊在某些業務中最快的選擇。 這裡有把Python用在PayPal的安全第一環境中的幾個以安全為基礎應用程式：
建立安全代理，以促進金鑰的輪換以並鞏固加密實現
同業界領先的 HSM 技術整合
為缺乏相容性的技術棧構建受TLS保護的封裝代理
為我們內部的互相認證計劃生成鍵和證書
開發主動的漏洞掃描器
另外，還有無數存在安全隱患的用Python構建，面向操作的系統， 諸如防火牆和連線管理。 未來，我們一定回去深入的整合PayPal Python的安全事項。
謬誤 #4: Python 是一門指令碼語言
Python 確實可以用來編寫指令碼，並且因其簡單的語法、跨平臺並且無所不在於 Linux， Macs， 和其它Unix 機器而成為這個領域的領跑者之一。
事實上， Python 可能是常規用途程式語言中最靈活的技術。 以下是一些例項：
電信基礎設施 （Twilio）
支付系統 （PayPal， Balanced Payments）
神經科學和心理學 （許多， 許多， 例子）
數值分析和工程 （numpy， numba， 以及 更多其它）
動畫（LucasArts， Disney， Dreamworks）
遊戲後臺 （Eve Online， Second Life， Battlefield， 以及 其它很多）
Email 基礎設施 （Mailman， Mailgun）
媒體儲存和處理 （YouTube， Instagram， Dropbox）
操作和系統管理 （Rackspace， OpenStack）
自然語言處理（NLTK）
機器學習和計算機版本 （scikit-learn， Orange， SimpleCV）
安全性和滲透性測試 （很多很多 以及 eBay/PayPal
大資料 （Disco， Hadoop support）
如理 （Calendar Server， 它 驅動了 Apple iCal）
搜尋系統 （ITA， Ultraseek， 還有 Google）
Internet 基礎設施 （DNS） （BIND 10）
更別提網站和web服務了，那些都不在少數。 事實上，PayPal工程師看起來像是有興趣致力於基於Python的web特性，比如 YouTube 和 Yelp。 如果對Python成功案例的更大清單感興趣，那就看看官方的清單吧。
謬誤 #5: Python 是弱型別的
Python 型別系統的特點是擁有強大、靈活的型別操作。 維基百科上對此作出的闡述。
而存在一個不爭而有趣的事實是， Python 是比Java更加強型別的。 Java 對於原生型別和物件區分了型別系統，它讓null存在於一個灰色地帶。 另一方面，現代的 Python 擁有一個統一的強型別系統， 其中什麼都沒有（None） 的型別是明確指定的。 更進一步的，JVM自身也是動態型別的，因為可以把它的 根源 追溯到由Sun所收購的Smalltalk VM的一個實現。
Python的型別系統 很棒，但要提供給企業級使用，目前仍然還有許多更重大的事項需要關注。
謬誤 #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的實現。
