2011年8月24日 星期三

認識核心團隊:Benjamin Peterson

原文網址 Meet the Team: Benjamin Peterson

這篇文章是「認識核心團隊」系列文章的一部分,目的是對 Python 核心開發團隊的成員來個簡短的介紹

姓名:Bejamin Peterson
位置:美國明尼蘇達州 (Minnesota, USA)
首頁:http://benjamin-peterson.org
部落格:http://pybites.blogspot.com

你使用 Python 有多長時間了?

三年半

你成為核心開發者有多久了?

到今年三月二十五號剛好滿三年

你是如何開始成為核心開發者的?你記得你第一次的提交嗎?

我第一次提案被 Guido 本人否決了 。幸運的是,我繼續堅持了下去並且也有些 patch 被接受了。我想我第一份提交是調整 Misc/ACKS 檔案的順序。

你現在負責 Python 的哪些部分

我喜歡語法分析器、編譯器以及直譯器的核心部分,不過大家都知道除了Windows 相關之外,我涉足於幾乎每一個 Python 的核心開發部分。

當你沒有在處理 Python 核心開發相關工作的時候,你都用 Python 來做些什麼?

我用它來實作 Python 直譯器 (http://pypy.org)!說真的,我打從心裡就是一個 Python 的實作者。 我是 six (http://pypi.python.org/pypi/six) 的創造者,six 是一個處理 Python 2 和 Python 3 之間相容性的程式庫。

當你沒在寫程式的時候你都在做些啥?

做音樂,吹豎笛還有讀些數學書,另外有時也會跑去爬山。

Python 核心開發輔導計畫

原文網址 The Python Core Mentorship Program .

Jesse Noller 在最近公告了 Python核心輔導 計畫 ( the Python Core Mentorship Program ), 這個計畫要讓學生,以及其他的專案的開發者可以得到導師的指導來降低進入 Python 核心開發的門檻。 而導師將會由有貢獻過 Python 核心程式碼經驗的程式設計師來擔任。

需要你的貢獻

不論你的經驗是多是少,導師們都會盡快回答問題,以親切的態度來給予回應。 想要貢獻程式碼的人會在整個開發流程中全程得到指導。像是如何在 mailing list 中討論問題,使用 bug tracker, Mercurial, code review,以及其他各種幫助。

Early Success

這個計畫目前已經在成功運作之中,參加者已經活躍地提交了許多patch。 在 mailing list 中也有相當多有建設性的討論,帶領人們在各個議題之中往正確方向前進。

準則

當想要貢獻程式碼時,新手可能不知道該如何拿捏與導師互動的分寸,也不知道如何善用mailing list。 因此、我們在這個 website 擬定了一份準則來舒緩疑慮。 長遠來看,這不只是對 Python 核心開發有所幫助, Jesse 以及其他的導師更希望這個計畫可以成為其他專案的典範,也期待可以增加 Python 核心開發者的多樣性。

報名吧

整個計畫是運作在 mailing list 上,也有一個清楚又明確的 website 。 你可能是個正要加入社群開始貢獻程式碼的菜鳥,也可能是個老手但依然對各方面充滿疑問。 這是一個絕佳的好機會來深入Python核心。加入我們,開始問問題吧,你將會在實作中得到寶貴的經驗。

2011年8月8日 星期一

Windows 的 Python 啟動器 ( Launcher )

原文網址: A Python Launcher For Windows

Mark Hammond ( pywin32 的作者及 Windows 上的 Python 長期支持者 ) 寫了 PEP 397 ,描述了 Windows 下新的 Python 啟動器。Vinay Sanjip ( 標準程式庫 logging 模組的作者 ) 最近實做了這個啟動器,下載地址是 https://bitbucket.org/vinay.sajip/pylauncher/downloads

啟動器允許 windows 上的 Python 腳本 ( .py and .pyw 檔案 ) 選擇要使用的 Python 版本,並可同時運行 Python 2 與 Python 3。

Windows 使用者可考慮下載並測試啟動器,幫助 Python 開發人員解決剩下的問題。該啟動器是獨立打包的應用程式,將支援目前可用的 Python 版本。我們的目標是當完成了一個啟動器,就將其加入 Python 3.3 中 ( 當然我們將會提供獨立下載包給之前版本的使用者 )

這個啟動器有兩個可用的版本 - launcher.msi 會安裝到 Program Files 目錄,而``launchsys.msi`` 會安裝到 Windows 的 System32 目錄底下。 ( 我們也提供 64位元 windowsws 的安裝版 )

啟動器的一些細節

完整的 PEP 397 啟動器行為規範,概括如下:

  • 該起動器提供兩個可執行檔 - py.exe ( 命令視窗版 ) 和 ``pyw.exe`` ( GUI 版 )。
  • 啟動器註冊了 .py ( CLI ) 和 .pyw ( GUI ) 檔案的副檔名 ( file extension ) 。
  • 當執行腳本時,啟動器會從腳本中找出 Unix 風格的 Shebang 識別 #!``。他會識別出可執行的 ``python ( 系統默認的 Python 版 ), python2 ( 預設的 Python 2 發行版 ) 和 python3 ( 預設的 Python 3 發行版 ) 這幾個字樣。各使用者或各臺機器可輕鬆地客製化設定確切的細節。
  • 單獨執行 py.exe 命令,會啟動 Python 交互解譯器。可由命令列參數設定欲使用的 Python 版本, py -2 啟動 Python 2 , py -3 啟動 Python 3,和 py 啟動預設的 Python 版本。

簡單的使用說明

安裝完成後,啟動器會自動關聯 .py and .pyw 檔案。 除非你有更改,腳本會使用機器預設的 Python 執行。有一樣設定你可能會喜歡,如果你經常使用命令視窗的話,增加 .py 到環境變數 PATHEXT 中,腳本就不用再額外開啟命令視窗執行了。

指定腳本使用 Python 2,只要簡單的將下面格式寫在第一行即可:

#!/usr/bin/env python2

( 上為相容於 Unix 的格式,如果你不需要與 Unix 相容,可用 #!python2 代替 )

另外,如果你想要指定腳本使用 Python 3,需在第一行增加:

#!/usr/bin/env python3

你也可以使用下列指令來啟動 Python 解譯器:

# Default version of Python py # Python 2 py -2 # Python 3 py -3

上述設定要能執行,必須先將 py.exe 加入環境變數。 launchsys 版的啟動器安裝程式會自動幫你做這個設定,但是需要你手動將 launcher.msi 的安裝目錄 ( C:\Program Files\Python Launcher ) 加入至環境變數 PATH 中。

延伸閱讀

下面幾個 python-dev 郵件組涵蓋了一些關鍵內容:

2011年8月7日 星期日

CPython 3.2.1 釋出

原文網址: CPython 3.2.1 Released

Python 的核心開發者、發佈經理(Release Manager) Georg Brandl 代表 Python-dev 團隊宣布 CPython 3.2.1 正式釋出。Windows 的安裝套件與 tarball 包已經在 7 月 10 日釋出。各位可以考慮升級到這個版本囉!

What's New 文件詳細列出 3.2 版的新特性,原始碼裡的 Misc/NEWS 檔案則列出所修正的 bug。

如果你在該釋出版或其他版本有發現任何問題的話,歡迎回報至 http://bugs.python.org/ 給開發者們。

2011年7月24日 星期日

輪詢對 future 模組及平行處理的影響

原文網址: Of polling, futures and parallel execution

現今的電腦運算最引人關注的問題之一就是如何省電。可攜式裝置對電力的使用更是錙銖必較。 當CPU閒置時,CPU可以進入各種低耗能的狀態。閒置的狀態持續得久,就會進入更深層的低耗能狀態, 也就會更加省電。因此充一次電,你的電池就可以撐得更久。

低耗能狀態有一個致命的大敵: 輪巡( polling ),若有一個工作(task) 定時地讓CPU離開閒置狀況, 不管所做的工作有多麼的簡單(好比只是檢查記憶上的一個數值),都會讓CPU 離開低耗能狀態, 把CPU內部所有組件都喚醒,卻在工作完成很久以後才會再進入低耗能閒置狀態。 這大大地減低了電池的壽命, 而 Intel 也關注這個 問題

Python 3.2 標準程式庫加入了一個新的模組 concurrent.futures module 來平行啟動工作並且會等待工作結束。當我在看這個模組的程式碼時, 我注意到它在部份的Worker thread 及 Worker procees 之中使用了輪詢。 我說部份是因為是因為 ThreadPoolExecutor 以及 ProcessPoolExecutor. 之間的實作是不一樣的。前者每一個worker thread 都輪詢, 而後者只會在負責溝通各個 worker process 的 management thread 輪詢。

輪詢這在裡只有一個作用: 偵測該何時啟動關閉程序。 其他的工作像是把 Callable 物件放進 queue 或是把運算的結果從 queue 裡面拿出來,是使用同步的 queue。 這些 queue 物件是由 threading 或是 multiprocessing 模組所提供的, 依照不同executor 實作而會使用不同的queue。

所以,我想到了一個簡單的 解法 : 我把輪詢換成了一個 sentinel, 就是內建的 None。 當queue 收到了 None, 一個在等待的 worker, 會自然地被喚醒然後去檢查是否該被關閉。 在 ProcessPoolExecutor 的實作裡, 情況會變得比較複雜, 因為我們不只是要喚醒一個 queue management thread, 更要額外喚醒多個 worker process。

在我一開始的patch 裡面,我還是會將論詢的timeout 設定為一個非常大的區間 (10分鐘), 因此 workers 將可以在某個時間點被喚醒。 會存在這麼大的timeout, 是為了避免有 bug 的程式碼讓程式沒有辨法經由前面說到的 sentinel 來執行關閉的程序。 出於好奇心,我觀察了一下 multiprocessing 的程式碼而且發現到了另一個有趣的問題。 在windows 平台上,當 multiprocessing.Queue.get() 在設定一個非零,非無限大的timeout的時候,windows 會使用...輪詢 ( 對此,我開啟了 issue 11668 )。 這個實作方式會使用迴圈加上高頻率的輪詢, 而每一次的輪詢會增加千分之一秒的 timeout。

不用說,這種時常喚醒系統的方式讓我的 patch 在 windows 上失去了我想達到的效果。 所以,我就把那個 10 分鐘的 timeout 移除了。 因為把這個timeout 設定移除了,那不管在那一個平台, 都不會再有系統被定期喚醒的問題了。

在 Python 3.2 以前,threading 模組及使用了 worker thread 的 multiprocessing 模組中的 timeout 機制都使用了輪詢,這將會在 issue 7316 中被修正。

2011年7月17日 星期日

在 Python 2.7 and 3.x 之間的 Deprecations

原文網址: Deprecations between Python 2.7 and 3.x

最近 在 python-dev 上面的討論 提到了關於目前開發者所遇到的從 Python 2.7 到 Python 3.x 時,Python 的 deprecation 政策問題。 由於考慮到 Python 使用者通常會直接從 Python 2.7 轉移到目前的最新 3.x 版,而不會關心舊版本,開發團隊對 deprecation 方針做了修改。

背景

Python 對於向下相容性有很強烈的承諾,除非可以符合相容性方針,否則不允許做出任何改變。 基本上來說也就是原本正確的程式不能在新版本的 Python 當中出錯。然而,這並不是永遠都能做到的, 舉例來說,當有某個 API 有很嚴重的問題並且需要被其他 API 替代的時候。在這種狀況之下, Python 依照 deprecation 方針:當某些特性要正式被移除的時候,會有一年的轉換期。 在這段期間,必須要有 deprecation 警告訊息來讓開發者有時間更新他們的程式碼。 關於 Python 的 deprecation 方針的細節在 PEP 5 有詳細的說明。由於只有在新的 Python 發行版本會有改變, 而且在發行版本之間通常都間隔了 18 個月,因此一次發行的 deprecation 周期剛好符合標準。

對於這個方針的有個例外是 Python 3。從 Python 2 到 Python 3 之間的主要版號變更就是特別為了允許破壞向下相容性的變更, 讓開發者有機會可以修正在目前方針之下無法修正的問題。舉例來說,讓字串預設為 Unicode,還有回傳 iterators 而不是 lists。

平行開發

轉移到 Python 3 會花上些時間,很多人估計大概是 5 年左右,所以 Python 2 和 Python 3 會平行開發一段時間。

由於 Python 2.7 會是 Python 2 的最終發行版本,大家都同意它的維護其將會被延長一大段時間。最後, 想要移到更新版本的開發者會需要跳到 Python 3。

以下是其中一個問題...

令人驚訝的 deprecation

一個 python-dev 的討論串 當中, 有個人指出了在 C API 當中的某個特定函式 PyCObject_AsVoidPtr 被移除了而沒有出現足夠的警告訊息。 然而這跟 deprecation 方針是相違背的!發生了什麼事情?

這個變更是從舊的 API (PyCObject) 轉移到更新、更好的 API (PyCapsule) 的一部份。 問題在於 PyCObject 在 Python 2.6 當中是預設而且唯一可用的 API。它在 Python 2.7 當中已經被標為 deprecated 了。 在 Python 3.2 這個 API 並不存在並且應該使用新的 PyCapsule 。這造成了一段大約七個月的 deprecation 周期 - 從 Python 2.7 的發行 (2010 年 7 月) 到 Python 3.2 的發行 (2011 年 2 月)。這比十二個月的最短周期還短的多, 並讓開發者很難對 Python 的發行版本做支援。

對於從 3.0 升級到 3.1 接著升到 3.2 的人來說,這個 deprecation 過程沒啥問題。 Python 3.1 在 2010 年 3 月發行時有這個 deprecation,並且在 3.x 的發行系列也都有, 因此有著將近 12 個月的的 deprecation 周期。但是這並不是人們通常的作法: 他們直接從 2.7 升級到最新的 3.x 版 (在這個案例是 3.2) 而造成了這個問題。 這從來不是 python-dev 的用意,但是 PEP5 提出的時候並沒有考慮到 Python 會同時有正在積極開發的並行版本。

所以我們該怎麼辦?

儘管 PyCObject/PyCapsule API 是個明顯的問題,這並不是不可能被處理的。 但是在 python-dev 上面至少有一個人為了處理這個問題遇到了一些困難。總而言之,這一切都不應該發生。

對於``PyCObject``/PyCapsule 的特例來說,這個問題已經存在而且我們也不能做些什麼。 重新恢復 PyCObject` 並不是一個選項,這將會增加更多的不相容性。然而,儘管會很繁瑣, 一般來說是可以寫出適合當前有提供的 API 的程式碼。事實上,在 Python 3.1 中, PyCObject API 是寫成 PyCapsule 的 wrapper。有人建議說如果有任何人需要, 在 Python 3.1 中的實作可以抽出來讓第三方程式碼使用。另外,大家也同意對於這變更要寫一份「有追溯力」的 PEP, 以便敘述在這變更之後的原因,並且說明可以幫助開發者轉移的資源。

簡單來說,Python 開發團隊現在已經認知到有這個問題並且會避免它再度發生。Guido 對這個狀況 發表了評論 並且建議目前 Python 3 對於 deprecations 的使用必須要保守一點。至少 deprecated API 在被移除之前必須要存在足夠久的時間, 給予從 2.7 轉移的開發者一條路走。

間接來說,這個討論串提出了要如何在短時間內有效率的讓 Python 的變更可以跟更多的人做交流, 這也是建立這個部落格想要解決的問題。

這些代表了什麼?

首先,這代表了 Python 開發者並不一定總是對的。沒人會想要讓開發者日子過得更苦,只是沒有及時發現這個問題。

再來,解決這個問題可能會帶來更多的麻煩,所以 PyCObject API 沒有重新被啟用。 儘管重新恢復 API 可能會幫助那些被這個變更傷害到的開發者,總體來說這會讓相容性問題更加的複雜。 同時,我們必須容忍這問題並且繼續往前邁進。我們已經學到了教訓,下次不會再犯下相同的錯誤。

這件事情也表現出 Python 開發團隊希望聽取使用者的意見。相容性是相當重要的, 大家也為了可以無痛轉移到新版本盡了每一份心力。尤其是函式庫的開發者會在合理的努力下希望能夠支援多個 Python 版本。

最後,開發者並沒有拋棄 Python 2.7,儘管在 2.7 並不會有新的特性,未來也不會有 Python 2.8 ,2.7 版使用者的看法還是很有影響力的。 讓使用者可以順利轉移到 3.x 版對整個 Python 社群來說是很重要的。

2011年7月3日 星期日

2011-04-06-正規化AST的異動控管策略

原文網址: Formalizing the AST Change Control Policy

Python 在 AST 模組中公開了抽象語法樹(abstract syntax tree [1], AST)用來呈現Python原始碼編譯過的形式。 AST 模組容許使用者的程式碼在原始碼分析與編譯過的bytecode之間對AST 表達式(representation) 進行檢視與操作。

雖然Python 原始碼的語義已經在 language reference 中被定義了,AST 模組只是CPython的實作細節,在其它的Python實作版本中沒有必要去實作它。

AST模組相容性

某些 工作 中需要在AST上對CPython 中的區域程式碼優化器(peephole optimizer [2] )進行全面改寫(而不是在bytecode 這層,就這個case 而言),為此 Eugene Toder 需要對AST的結構進行修改。AST 作為一個CPython實作上的細節,沒辦法立即明瞭它是否也採用向後相容策略。 為此, Eugene向python-dev 問了這個問題 。 在修改AST時是否需要確保它的向後相容性?

一般來說社群裡一致同意 沒必要 去考量向後相容。AST 模組對外公開了一個常數 ast.__version__ , 讓使用者的程式碼得以依照AST的版本資訊對於它的程式行為自行調整。對於一個與實作版本相關的模組而言,這 樣子已經提供了足夠的相容性了。

其它 Python 的實作版本

事實上,Jython 和 IronPython 的維護者們指出他們各自的實作版本要嘛擁有一個相容的AST模組或是 傾向提供一個。即便如此,他們並不認為這代表 AST 模組應該被凍結發展並且樂見隨著 ast.__version__ 常數的更動,能在不用考慮相容性下修改AST模組。

有一個被提出的觀點指出在 test_ast.py 中的完整 test suite 可以幫助其它的實作 版本確保它們的 AST 表達式與 CPython 相容。 增加 test_ast.py 的涵蓋對於想要參與 Python 內部運作的的人們是一個好的 Project。

之後會發生什麼?

開啟這個討論串的 patch截至目前為止尚未 被整進 CPython中。 有可能,什麼事都不會發生。無論如何,如果它真的被commit了,AST 將會 以不向後相容的形式存在。 ast.__version__ 這個常數將會隨之更動來對應, 這樣子使用者們的程式碼才會知道可是程式也要隨之改動。概括來說,這將是未來AST更動 後要處理的方式。

Python 的開發者們對於這個策略被採用後,對已使用 AST的程式影響有多廣多深很有興趣。 如果有讀者們的程式會因為AST變更而受到影響,鼓勵大家去參與 在python-dev上的討論


[1]譯註: 關於 AST 可參閱 Wiki上的解釋
[2]譯註: 它的基本概念是為瞭解決statement by statement translation 可能會產生冗餘code的問題, 所以它在最佳化的時候是一次看一小段程式碼進行優化的動作,可以參閱 薛智文老師的投影片Wiki上的解釋

2011年6月30日 星期四

Python 3.3 將停止支援 OS/2, Windows 2000 以及 VMS

原文網址: Python 3.3 to Drop Support for OS/2, Windows 2000, and VMS

每隔一段時間, 我們會依據使用的狀況來縮減支援作業系統列表. 除此之外, 由於必須有人可以完成開發的工作來保證產生品質良好的發行版本, 平台上有足夠的開發人員數量也是一個很重要的考量. 像是作業系統的年紀, 以及作業系統的開發是否有遭遇到阻礙等等的其他因素, 也將會是考量的一部分.

Victor Stinner 最近在他提出了對 OS/2 支援的 最初問題 的一年之後, 提議 CPython 停止支援 OS/2 和 VMS. Victor 的詢問來自他似乎不停的花力氣在處理 Unicode 的問題上面, 尤其是 os.execvpe() 在透過 PEP 383 中的 surrogateescape handler 來支援環境變數的問題. OS/2 和 VMS 目前沒有開發團隊的代表人, 而且在發行的過程當中也沒有收到任何測試.

在寫這篇文章的過程當中 讓我想到 了從前關於移除支援 Windows 2000 的 討論, 不過之前的討論似乎被擱置了. 在當時, 將 COMSPEC 設定為 command.com 的系統也被提出要不再繼續支援. 現在開始, 他們都加入了 OS/2 和 VMS 的行列. 為了要讓開發更容易一些, Windows 2000 將會被移除, 這樣就不需要考慮那些在 2010 年結束生命的作業系統當中的老舊 API 了.

為了要開始移除對這些作業系統的支援, Victor 跟我從更新 PEP 11 開始.

PEP 11

這份 PEP 列出了不再繼續支援的作業系統, 並且解釋了把作業系統增加到這份 list 的過程.

當一個作業系統開始進入移除程序, 它將會被正式的被宣告為不再繼續支援. 這份公告通常都是在開發中的版本生效, 所以將從 Python 3.3 開始取消對於 OS/@, Windows 2000 以及 VMS 的支援.

第一個階段僅僅是袖手旁觀, 大概就像是舉起白旗一樣. 這告訴大家目前沒有人可以繼續維護程式碼並確定會有一份有品質的發行版本. 為了警告使用者這份平台將不再繼續被支援, 編譯以及安裝的過程也將可能被改變. 在 "What's New" 當中也會被註明有哪些平台將不再繼續被支援.

在一個發行周期之後, 之後的版本將會進入移除程式碼的過程. 在這次的例子來看, 程式碼可以在 3.4 版被移除. 儘管不一定所有的程式碼都會被移除, 但是開發者可能會移除任何 #ifdef, configure 或是其他過期的程式碼.

你能夠做什麼

如果你是一個 OS/2 或 VMS 的使用者, 你能夠作到這幾件事情來拯救你的平台.

成為一個維護者

一個積極的開發者就是最棒的支援. Andrew MacIntyre 成為 OS/2 的維護者有很長的一段時間了, 他在 Victor 第一次提問的時候就說過了 OS/2 對於 Unicode 的支援已經很落後了, 所以這毫無疑問的是一個需要注意的地方. VMS 目前可以從 http://www.vmspython.org 獲得一些外部的支援, 不過就如同在 issue 11918 當中討論過的, 我們還是需要某人站出來讓 VMS 上游的支援繼續下去.

如果你想要接手這兩個平台之一, 請參考 developer's guide 看看目前的發展狀況.

貢獻一台 build slave

有積極開發者的平台會有比較大的機率存活, 有 build slave 的平台存活機率將會更高. 不僅僅是存活的機會變高而已, 品質也會受到保障.

Python 使用 Buildbot 來做持續整合, bulid slaves 目前有提供 Linux, Mac, Windows, 以及 Open Indiana (Solaris) 各種不同平台, 配置的版本. 貢獻一台建構 OS/2 或是 VMS 的機器將可以讓這些平台接受到如同其他主流平台一樣的關注.

如果你可以提供你的時間或是硬體來幫助 OS/2 和 VMS 繼續存活下去, 請和 python-dev 的郵件列表連繫, 我們會協調看看你能做些什麼.

2011年6月19日 星期日

urllib/urllib2 安全性問題修正

原文的網址 urllib Security Vulnerability Fixed

Guido van Rossum 針對 CVE-2011-1521 中提到的 Python URL 程式庫安全性問題 最近送了一份修正. 儘管很少有安全性上的問題, 這是個讓社群了解到當問題產生時要如何報告, 處理以及修正的好機會.

報告問題

如果你在 CPython 當中發現安全性問題, 我們首先希望你隱藏問題的細節. 在確定你發現了一個真正的安全性問題之後, 產生一份簡潔但是詳細的報告是將你所知道的狀況傳達給核心開發人員的關鍵.

一份好的報告清楚的解釋這個問題會影響到系統當中的哪些相關部份. 如果這個問題發生在特定的平台或是由於相依性造成, 報告這些也會有幫助. 儘管這個漏洞通常都會在所有的有效版本當中被測試, 報告有哪些版本被影響也會有幫助. 最後, 如果你有測試資料可以重現這個問題, 也請在報告當中附上. 請將你的報告寄到 security@python.org.

在 Google Security Team 的 Niels Heinen 最近 提交了一份很好的報告. 他發現到在標準程式庫 urlliburllib2 模組當中關於 HTTP 302 處理重導的問題. 伺服器可能會將重導的要求轉至不適當的地方, 這種情況可能會造成對資料或是系統的危害. 在他的報告當中, Neils 解釋了兩種會顯露出這個問題的狀況.

首先, 由於 urllib/urllib2 支援處理 file:// 的 URL, 對於 file:///etc/passwd 的重導將會暴露出密碼資料. Neils 也解釋了重導到像是 file:///dev/zero 的系統設備可能會導致系統資源的耗損, 造成阻斷服務攻擊.

處理報告

由於安全性報告相當敏感, 僅有少數可被信賴的開發者維護著 security@python.org 的列表, 他們將會盡快地處理這些報告. 如果你希望將你傳輸的報告加密, 請參考 security news 頁面中關於 OpenPGP 的細節.

如果確定了的確有一個安全性問題, 一份公開的 bug 報告將會隨著一份修正被釋出. 在這個案例中, Guido van Rossum 在 issue #11662 當中公開了這個問題, 並且伴隨著一份修正.

解決問題

Guido 的修正所做的是限制重導只能夠重導到 http://, https:// 以及 ftp://. FTP 重導原本就被視為可接受, 它是個相當常見的重導: 鏡像下載系統會把下載的要求重導到比較近的 FTP 伺服器.

對於 Python 2.x 來說, FancyURLopenerredirect_internal 方法現在會在重導到不恰當的 URL 時產生 IOError 例外. HTTPRedirectHandlerhttp_error_302 也會作同樣的事情, 它將會產生 HTTPError 例外. 在 Python 3 當中, urllib.request 也有同樣的修正. 在這份修正中, 也包含了兩份會重導到合法以及不合法 URL 的實際測試.

對於接受修正的使用者, Python 2.5 最終的安全發行版將會很快的釋出. 儘管對於 2.6, 2.7, 3.1 以及 3.2 這些其他的維護分支來說, 目前還沒有預定的修正日期, 但是這些版本都已經收錄解決此問題的修正.

2011年6月8日 星期三

2011 Python 語言高峰會簡報

原文網址 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。

更多資訊

想知道更多的資訊的話,請看CPython 的開發人員 Nick Coghlan 的 rough noteshighlights.

2011年6月2日 星期四

Python 3.3 中,幫助除錯的新模組-- faulthandler

原文網址 New faulthandler module in Python 3.3 helps debugging

當一名使用者跟你回報你的程式當掉或是卡住不動了,有的時候你只能盡力收集程式運行時資料, 並且確立使用方式來重現當時的狀況。 但就算你已經很清楚使用者如何使用你的程式,你也常常無法重現一樣的症狀,因為使用者的執行環境跟你的不一樣, 比如說作業系統或是編譯器的不同。如果運氣夠好的話,使用者可以安裝除錯工具,但大部份的情況下你只能期待另一個人在出了一樣的錯後能提供更多資訊來幫助你找到問題的根源。

嚴重錯誤

Python 3.3 加入了一個新的模組 faulthandler 來幫助程式設計師面對這個問題。 faulthandler 讓你在發生嚴重錯誤 時可以追朔執行過的程式碼。比如說數學運算時,分母為零( division by zero) 、異常中止( abort )、匯流排錯誤( bus error )。 你可以在你程式中使用 faulthandler.enable() 來開啟這個功能。或是在Python啟動時指定 -X faulthandler 這個選項。又或著是設定 PYTHONFAULTHANDLER=1 這個環境變數。 開啟後,程行遇到問題當掉後就可以看到類似下面的畫面:

Fatal Python error: Segmentation fault

Current thread 0x00007f7babc6b700:
  File "Lib/test/crashers/gc_inspection.py", line 29 in g
  File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault

運行超時( Timeout )

faulthandler 也可以偵測程式執行超時( timeout )。使用 faulthandler.dump_tracebacks_later(later) 來開始計算程式的運作時間, faulthandler.cancel_dump_tracebacks_later() 可以停止計時。 當執行超時發生,的產生的結果如下:

Timeout (0:01:00)!
Current thread 0x00007f987d459700:
  File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>

使用 repeat=True ,則每一次超出執行時間都會印出如上的畫面,或著指定 exit=True 來立刻關閉程式。 但這比較不安全,比如說這樣做沒有確實清空檔案的緩衝區。

由發出訊號來觀察執行狀況

我們更可以靠發出訊號給程式來追朔執行狀況,你可以用 faulthandler.register(signal) ,指定用發出訊號的方式趨使程式印出程式的執行狀況。 比如說在 UNIX上,你可以使用 SIGUSR1 : kill -USR1 <pid> 來讓你的程式印出當時的情況。 不過windows 是沒有這個功能的。 輸出會如下:

Current thread 0x00007fdc3da74700:
  File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>

另外,你可以用 faulthandler.dump_traceback() 來在任何時候自已印出執行狀況。

安全性考量以及所用的輸出檔案

由於安全性的考量 faulthandler 預設是關閉的。 會這麼做的主要原因是它會輸出結果到 sys.stderr 但如果sys.stder 被關閉了,且 sys.stderr 檔案描述子( file descriptor )被重用了, 我們的執行狀況就會被輸出到其他的地方,像是管線 (pipe)、socket、 或是某些檔案。這樣有可能讓存在程式中的敏感資料無意間洩露出去。 faulthandler 預設是使用 sys.stderr ,不過你可以選擇別的檔案。參考 faulthandler documentation 來了解更多的資訊。

舊的Python 也可以用

faulthandler 將會以第三方模組的型式放在 PyPI 上, 並且支援 Python 2.5 到 3.2。 但與3.3版相較,最大的不同是在 dump_tracebacks_later 的實作上: Python 3.3 使用執行緒並且運用一個有time out 機制的 lock。 而第三方函式庫實作的版本是使用 SIGALRM 以及 alarm()

Lock timeout 是 Python 3.3 的新功能,它計算時間的精準度可以達到百萬之一秒。 而使用 alarm() 的舊版 Python 的計時精準度只能達到秒的程度。 而且使用 SIGALRM 有可能中斷正在執行的系統呼叫( system call ),產生 EINTR 錯誤 (譯注: 關於 EINTR, 可以參考這篇 Python - Pipe 在 Signal 發生時的處理事項 ) 。

它真的有用

這個新的 faulthandler 模組已經幫助我們找到我們自已的編譯程式中存在的 race conditions。我們期望這也可以為你帶來幫助。

2011年5月8日 星期日

Jython 轉移到了 Mercurial

原文的網址: Jython Migrates to Mercurial

經過了一翻辛苦的幸苦的工作之後,Jython 終於從Subversion 轉移到了 Mercurial。

這個新的官方 repository 現在host 在
_http://hg.python.org/jython
同時也有一個 BitBucket Mirror ,讓開發者可以輕易地fork.

正在開發的功能則會放在唯讀的repository http://hg.python.org/jython-fullhistory ( 會轉換成 Mercurial Bookmarks )

Mercurial 讓開發者可以輕易的對 Jython 產生貢獻, 現在就立刻pull 一個fork, 然後來幫助我們建置 Jython 2.6 吧!

歡迎來到 Python Insider!

原文的網址: Welcome to Python Insider!

Python Insider 是Python 核心開發團隊的官方部落格,這個部落格讓沒有訂閱 Python-Dev mailing list 的朋友可以了解現在開發團隊的開發狀況,更可以了 解Python 所即將發生的改變。我們可能會寫的文章如下:Python source code 既將要完整地使用 Mercurial 來做程式碼的版本控管。新接受的Python Enhancement Proposals (PEPs), API 的變化, 以及一些主要的核心開發工作。

這個部落格不是取代既有的 python-dev mailing list 以及每一位開發者的部落格。 而是提供一個公開的管道來討論一些剛完成的計畫,或是當計畫需要更多人力時,可以在這裡找到更多熱心的志願者。這個部落歡迎討論,但我們希望對這些話題有興趣的朋有可以移師到我們的 python-dev mailing list 來直接參與開發及討論。

所以,就請把這個部落格當成這是讓你了解Python 未來走向的一種管道。

訂閱

這裡有各種方法可以讓你跟隨 Python Insider 的最新文章:

我們需要你!!

儘管我們有一個小組的作家來發表文章,但還需要網頁設計的人員來翻新Blogger的template。 同時,正體中文的翻譯也很需要人手,如果想助我們一臂力的話,請聯繫 Doug Hellmann (doug dot hellmann at gmail).