原文網址 2011 Language Summit Report
今年的Python語言高峰會(Language Summit)是在三月十日禮拜四(在PyCon的前一天)舉辨在亞特蘭大。
參與的成員來自各個跟Python有關的專案，比如說: CPython, PyPy, Jython, IronPython,以及 Parrot VMs ;
Fedora, Ubuntu, 以及 Debian 的套件開發成員; Twisted 以及其它專案的成員。
開發狀況部落格
由於 python-dev mailing-list 流量十分龐大，Doung Hellmann( PSF 的Communications Officer)，打算開一個部落格讓
使用者可以用比較輕易的方式得到python的開發新聞 (就是你現在看到的這個)。主題內容打算包括 PEP( Python Enhancement Proposal )，未來走向，新功能，還有重要的bug fix。
也將會包含開發流程的的改變。
這個部落格接受各種Python的實作品來發表文章，比如說儘管PyPy已經有了 自已的部落格 。 但依然歡迎在這裡發表新聞。
經過一陣相關的討論之後，我們把其它的實作品也放在 python.org 的下載頁裡了 。
這些新的實作在釋出的時後，也同時會在 python.org官方首頁 裡同步更新。
相容性警告
在3.2版的Python 裡，我們引進了 ResourceWarning 來幫助使用者找到依賴 CPython 引用計數( reference counting )
的程式碼。這個警告不只是要幫助使用者寫出更好的程式碼，
更可以讓使用者寫出更安全的跨VM實作品的程式碼，為了更進一步強化各種VM實作品之間的相容性，
我們提出了新型態的警告: CompatibilityWarning.
這個想法會被提出是起源於一個被PyPy開發者所發現的CPython Bug。
Issue #11455 敘述 CPython 允許使用者可以自定出 __dict__ 的key不為字串的型態。
而PyPy 及Jython 目前並不支持這種做法。理想上來說，使用者可以開啟警告來發現這種狀況，就如同 ResourceWarning 的作法一樣。
獨立標準函式庫
在 CPython 從 Subversion 轉移到了 Mercurial 之後，把Python 的標準函式庫抽離開來另外維護的想法又被提了出來。
其他的Python實作品的開發者對這轉變非常感與趣，因為這可以大大的簡化他們現在的工作流程。
現在的流程會抽出 CPython 某一個時間點的標準函式庫，為這些函式庫上些實作相關的 patch，再把 C 的 extension 換成完全
使用 Python寫的版本。
目前正在計畫把這樣的轉變寫在以後的PEP 裡。
其中有個討論是該如何訂出版號。由於標準函式將會獨立於各種實作之外，所以最可能的方向是有自已獨立的版本，
但因此，做測試時就要顧及直譯器版本，而不能像以前一樣，只要測試同時發佈的Python 直譯器就可以了。
另一個關於標準函式庫的話題是關於那些同時另外有一份C 語言 extension 的模組。
PyPy 中的一位成員，Maciej Fijalkowski 提到隨著時間的演進，這些模組之間的功能已經所差無幾了。既然有打算把標準函式獨立出去，
希望這種模組的更動可以嚴格一點，以免造成太大的負擔。也希望只有在效能太過低落的時候，才引進C 語言 extension。
效能測試
PyPy 效能研究中心( PyPy Speed Center )，很清楚的展示了PyPy 的效能強大的地方。
所以開始討論 python.org 也可以有一個類似的網站。比如像是 performance.python.org 這種名字。
而且也會評估其他各式Python 實作品的效能。除了效能之外，記憶體的使用量，語言的相容性也應該展示出來。
這將會花費不少功夫在建立基本設施上來測試各種 Python 實作品，如同現在PyPy 跟 CPython 的比較。
在 奧瑞岡州(Oregon) 大學Open Source 實驗室 服務的 Allison Randa 將會主持這些效能測試。
這樣子的測需要許多高效能的主機，Jesse Noller 歡迎大家捐贈機器。
有興趣的朋友，請送到 Python Software Foundation 並且看一下我們的 捐贈頁面 ，
來了解我們的需求。
解除Python 3.3 的束縛
從CPython 3.3開始，我們不再凍結語言本身的變化。儘管水庫的閘門已經打開了，我們會放慢改變的速度，以期讓其它語言的實作品可以趕上Python 3.X 的進度。
目前 IronPython 以及 PyPy 已經是 2.7 相容了。而 IronPython 已經向Python 3.x 相容邁進。
3.3 預期會接納 PEP 380 , 這個 PEP 引入了新的語法，``yield from <expr>``，讓generator 可以``yield``
另一個generator。除此之外，Python語言近期內不會有改變。
例外屬性
下一個討論的主題是讓例外(exception)提供更有的意義的屬性， 而不是讓使用者單單只靠字串訊息來判斷情勢。
比如說，當遇到ImportError時，以往要分析錯誤訊息才知道道是那個模組import 失敗了。如果可以簡單地知道是什麼模組import 發生了錯誤才是實用的做法。
實做上可能只會使用Keyword 參數來初使化這些例外物件，目前已經有現成的 ImportError Patch 可以參考。
開發者協定
我們也提到了開發者協定( Contributor Agreements ), 目前已有了大概的雛型。
其中一個啟發我們的是Google的 個人開發者協定
這個議題已經被討論了很久，很多人很期待可以明確的訂定這個協定。除此之外，我們也會確保在美國之外，這個協定也可以保持效用。
Google Summer of Code
Martin von Löwis 花了一分鐘介紹了今年的Google Summer of Code，開發者不只可以扮演導師，更可以提出你想做的計畫來讓學生完成。
而且提出計畫的人也不一定要指導學生。如果你有興趣幫忙的話，請看 PSF 的 尋求點子及導師.
Distutils
Distutils2 即將完成， Tarek Ziadé 提到他們下一次衝刺的目標是完成Python 3 的移植以及合併回標準函式庫。除此之外，合併後將會改成一個新名字，``packaging``, 這個 packaging 團隊還會計畫提供獨立的套件叫做 Distutils2，來持續支援 Python 2.4 到 3.2。
這個計畫目前非常成功，目前的結果在 Bitbucket, 且正在等待
合併回標準函式庫。
其他實作品的未來藍圖
IronPython 提及到了他們的未來計畫而且他們將會立即著手3.x版的開發。 他們在PyCon 上發佈了2.7 版。
2.7 版是他們的第一個基於社群的版本，因為這個計畫已經從微軟接手了過來。而且在在這幾個月內往3.x 版邁進。
Jython 最近才剛發佈了 2.5.2版，而且開始計畫 2.6版。由於2.6版和2.7版的差別不大，一些人計畫跳過2.6版，直接開發2.7版。
但是這麼做的話，開發的時程會拉得比較長。基於早點發佈，時常更新的哲學。Jython不太可能從2.6 跳到3.x 版。而會穩當地開發2.6版及2.7版。
開發讚助
讚助開發工作有機會可以讓那些不同的Python實作品加速他們的實作到相容3.x的地步。當有讚助後，
請把計畫提到PSF，才有機會可以運用那些讚助。 那些有興趣收受讚助的團體，請聯詻PSF。
基本款的Python
Jim Fulton 開始討論到他稱之為基本款(baseline) 的Python。在他佈署Python程式的經驗之中，
有太多不可預期的狀況發生。由於有 Ubuntu/Debian 的 packaging 專家，我們才可以知道問題的全貌與由來。
以Fedora 上所安裝的Python 的情況的來說，Python 以 Live CD 可以正常運作為目標，所以只安裝非常小的部份。
資料夾的位置也有所不同，比如說有一些函式庫從標凖函式庫之中移除了( 像是 distutils )，或是有一些
發行的版本提供了老舊的函式庫。
這件事還沒有明確的解法，但相關的人士已經在著手處理這個問題。
3.3 新功能
開始提到 3.3 的特色。包含了 兩個PEP :
PEP 382 ， 有命名空間( name space )的套件.也討論到該怎麼和 distutils 整合。
也討論到 PEP 393, 一個較有彈性的內部字串表示。
這吸引了一些學生想在GSoC參與這個project。不過在實做上，但也要考慮效能及記憶體管理，才有可能被Python Foundation 接受。
Unladen Swallow
Unladen Swallow 現在處在"停工"的狀態，未來也不會包含在 CPython 3.3之中。
為了讓這個計畫可以有所進展，由於目前沒有專門的人來負責。
我們需要更多成員來加入這個計畫。也討論到如果需要資助才有辨法將
Unladen Swallow 的品質提昇到更高的層次的話。請有興趣的組織聯絡 PSF
雖然 Unladen Swallow 正在停工中且不確定未來走向。這個計畫還是對 Python 及其他一般
的開源計畫有很大的幫助，比如說Unladen Swallow 的效能測試可以拿來測其他語言的實作品。
Unladen Swallow 的開發者也對 LLVM 及 Clang，提供了很多的貢獻。
別的效能提昇的想法也被簡短地提到了。包括了 Dave Malcolm 的函式inline 的想法。
Martin von Löwis 提到了他正在著手的即時編譯(JIT)的擴充模組，儘管PyPy的開發者對
這一種即時編譯的效果存有疑問。
邁向非同步的開發框架(frameworks)
今天的最後一項討論是把Twisted 整合進標準函式庫裡。主要的想法的想法是想要有另一個類似 asyncore 的模組，
可以讓Twisted 或其它的非同步的框架可以較容易整合進來。
這個過程也會被寫進PEP裡面，一些人建議可以把這個PEP寫得像是WSGI一樣，但是對象是針對非同步的事件。
除了這篇PEP的作者之外，Twisted 專案以及其他的類似計畫的人都會花費心力一起完成這個Proposal。
