2011年5月24日火曜日

Python コアメンターシッププログラム

原文はこちら: The Python Core Mentorship Program

Jesse Noller は、最近 Python コアメンターシップ プログラムの設立を 発表しました 。このプログラムの背景にある想いは、学生や他プロジェクトの開発者を含めた幅広いプログラマに対して、メンター (指導者) として協力してくれる経験豊富な貢献者とやり取りして、Python コア開発を楽しんでもらえるように手を差し伸べることです。

貢献者の募集


メンターたちは経験のレベルに関わらず、貢献者たちとけんか腰で接さず快適な雰囲気で必要な情報を教えたり、質問に答えたりするのに協力します。貢献者は、関連メーリングリストの議論、バグトラッカー、Mercurial、コードレビュー、その他全てを含むプロジェクトに貢献するプロセス全体を通して助言を受けます。

早期の成功


このプログラムは既に成功を収め、その参加者は積極的にたくさんのパッチをコミットしています。さらに、メーリングリストで多方面から建設的な議論が行われ、多くの問題に対する正しい方向付けとなる道しるべになっています。

行動規範


このプログラムは、 ウェブサイト で行動規範を紹介しています。この行動規範は、多くの新たな貢献者が、メーリングリストや経験豊富な開発者とやり取りするときに、普通に抱くような不安や懸念を和らげることを目的としています。Jesse やその他のメンターたちは、このプログラムが Python コア開発の利益になるだけでなく、長期的には他のプロジェクトのモデルの1つにもなり得ることを期待しています。さらに Python の貢献者全体の多様性を高めるのにもつながることを望んでいます。

参加表明


このプログラムは メーリングリスト を通して行われ、分かりやすく簡潔な専用の ウェブサイト もあります。もしも、あなたが質問することからコア開発を始めてみたいと考えている。または、あなたが (Python コア開発も) 経験のある開発者であっても、他のメーリングリストへ投稿しようか気がかりな質問をもっているのなら、それはまたとない絶好の機会です。まずは質問することから始めてみましょう!

2011年5月20日金曜日

ポルトガル語、ドイツ語、韓国語、中国語 (繁体字) の翻訳

原文はこちら: Portuguese, German, Korean, and Traditional Chinese Translations

Python Insider の 翻訳プロジェクト は今も拡大を続けています! ポルトガル語, ドイツ語, 韓国語, 中国語 (繁体字) の翻訳ブログを立ち上げました。各言語のブログの翻訳者は、既に過去の記事の翻訳を進めています。他の翻訳ブログと同様に、これらの並列した翻訳ブログは、オリジナルの Python Insider の記事から少し遅れるかもしれません。

2011年5月14日土曜日

Python 3.3 で導入されるデバッグに役立つ faulthandler モジュール

原文はこちら: New faulthandler module in Python 3.3 helps debugging

プログラムが強制終了したり、固まったりしたことをユーザが報告する際にできることは、その状況の再現手順の概要とより詳細な情報を収集しようとすることだけです。信頼できるユーザーからの再現手順であっても、オペレーティングシステムやコンパイラといった環境の違いから、開発者として再現できないこともよくあります。運が良ければ、ユーザーがデバッグツールをインストールしてくれますが、誰かが同じ環境で詳細な情報を収集してくれるまで、ほとんどの時間を待っていなければなりません。

致命的なエラー


Python 3.3 で導入される新たなモジュール faulthandler は、この問題に役立ちます。 faulthandler は、セグメンテーションフォールト、ゼロ除算、処理の中断、バスエラーといった致命的なエラーのトレースバックをダンプする機能を提供します。Python の実行ファイルに対して -X faulthandler オプションを指定するか、もしくは環境変数 PYTHONFAULTHANDLER=1 を設定してから、 faulthandler.enable() を使ってアプリケーション内部で有効化します。出力結果は次のようになります。
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

タイムアウト


faulthandler は、 faulthandler.dump_tracebacks_later(timeout) を使って、タイムアウトした後にトレースバックをダンプすることもできます。そのタイマーを再起動するために再び呼び出すか、そのタイマーを停止するために faulthandler.cancel_dump_tracebacks_later() を呼び出します。出力結果は次のようになります。
Timeout (0:01:00)!
Current thread 0x00007f987d459700:
  File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>
timeout 秒毎にトレースバックをダンプするには repeat=True オプションを使ってください。または、そのプログラムが不安定な状態のときに、例えばファイルをフラッシュせずに、すぐに終了するには exit=True を使ってください。

ユーザシグナル


プログラムを実行しているホストへアクセスできるなら、 signal を受け取ったときに、トレースバックをダンプするシグナルハンドラをインストールするために faulthandler.register(signal) を使ってください。UNIX 上では、例えば、 SIGUSR1 シグナルを使えます。 kill -USR1 <pid> は、カレントのトレースバックをダンプします。この機能は Windows 上では使えません。出力結果は次のようになります。
Current thread 0x00007fdc3da74700:
  File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>
もう1つの方法は、プログラム内で明示的に faulthandler.dump_traceback() を呼び出します。

セキュリティの問題と出力ファイル


faulthandler は、セキュリティの理由からデフォルトで無効化されています。その主な理由は sys.stderr のファイルディスクリプタに保存して、そこへトレースバックを書き込むからです。もし sys.stderr がクローズされて、ファイルディスクリプタが再利用される場合、そのファイルディスクリプタはソケット、パイプ、重要なファイル、またはその他に使われる可能性があります。デフォルトでは、 faulthandler はトレースバックを sys.stderr へ書き込みますが、別のファイルも指定できます。詳細は faulthandler ドキュメント を参照してください。

古い Python バージョン向けのサードパーティモジュール


さらに faulthandler は、 PyPI 上で Python 2.5 から 3.2 を対象としたサードパーティーモジュールとしてメンテナンスされています。Python 3.3 のモジュールとサードパーティモジュール間での主な違いは dump_tracebacks_later() の実装です。Python 3.3 は、ロックのタイムアウトをもつスレッドを使うのに対して、サードパーティモジュールは SIGALRMalarm() を使います。

Python 3.3 の新機能であるロックのタイムアウトは、マイクロ秒単位の精度です。旧バージョンで使われる alarm() タイマーは、秒単位の精度です。さらに SIGALRM シグナルは、 EINTR エラーで失敗したカレントのシステムコールを中断させる可能性があります。

早期の成功


新たな faulthandler モジュールは、既に buildbot の競合状態を追跡するのに役立っています。このモジュールがあなたのプログラムにおいても役立つことを願っています。

2011年5月9日月曜日

ルーマニア語と中国語 (簡体字) の翻訳

原文はこちら: Romanian and Simplified Chinese Translations

今日、Python Insider チームは、新たに2つのブログの発表ができるのをとても嬉しく思います。 ルーマニア語中国語 (簡体字) の翻訳者が 翻訳プロジェクト に参加しました。そして、既に公開済みの記事の翻訳が始められています。その他の言語の翻訳と同様に、これらの並行した翻訳ブログは、オリジナルの Python Insider の記事から少し遅れるかもしれません。

2011年5月8日日曜日

Jython リポジトリを Mercurial へ移行

原文はこちら: Jython Migrates to Mercurial

Jython リポジトリが Subversion から Mercurial へようやく移行しました。不運にも Subversion のリポジトリから別のリビジョン管理システムへきれいに移行するのが難しく、この作業には長い時間がかかりました。

新たな Jython の公式リポジトリは、以下にホスティングされています。

http://hg.python.org/jython

このリポジトリは BitBucket ミラー があり、簡単にソースを分岐させられます。

また、(Mercurial ブックマーク に変換された) 開発用ブランチをもつ大きな読み取り専用リポジトリも http://hg.python.org/jython-fullhistory でホスティングされています。

Mercurial に移行したことで Jython への貢献、リポジトリの分岐、Jython 2.6 のビルドを手伝ったりするのがもっと簡単になります!

2011年5月7日土曜日

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 のサポートに関する 当初の質問 の1年後に、CPython の OS/2 と VMS のサポートをやめること を最近、提案しました。Victor の当初の質問は、一見したところ、Unicode の取り組みに関することで、具体的には PEP 383 のサロゲートエスケープハンドラ経由で環境変数をサポートする os.execvpe() の問題でした。OS/2 と VMS は、現在、開発チームへの参加表明もなく、リリースプロセスにおいてもテストされていません。

この記事を書く過程において、その辺の道ばたに捨ててあると思われる Windows 2000 のサポートをやめる 以前の議論 についても 私は考えさせられましたCOMSPEC から command.com に変更するシステム設定も逃げ場のない状況だと仮定されました。 いまのところ 、Windows 2000 と COMSPEC の2つも OS/2 と VMS に加えて追加されました。Windows 2000 は、2010年にそのサポートが終了し、オペレーティングシステムのレガシー API に対応する義務を減らすことで、開発が楽になるのでサポートをやめる予定です。

こういったシステムのサポートをやめるために、Victor と私は PEP 11 を更新することから始めました。

PEP 11


この PEP は、もうサポートされていないオペレーティングシステムの概要と、そのリストへそういったシステムを追加するためのプロセスを説明します。

あるオペレーティングシステムのサポートをやめるプロセスが開始できると決定した時点で正式にサポート終了として発表します。この発表は伝統的に開発中のバージョンから適用されるので、Python 3.3 から OS/2, Windows 2000, VMS のサポートをやめます。

最初の段階は、適正に引き継ぐというよりも白旗を揚げます。これは誰もそのコードをメンテナンスせず、そのリリースの品質を保証しないという合図です。対象のプラットフォームを利用するユーザに対して、そのプラットフォームはサポートしないと警告を出すように、コンパイルやインストールに変更が行われます。"What's New" のドキュメントに、新たにサポートが終了したプラットフォームのリストが注釈として追加されます。

サポートをやめるリリースサイクルとしては、その次のバージョンで適正にそのコードが削除されます。この場合は 3.4 でそのコードを削除します。おそらくコードの削除は大掛かりなものにならないはずですが、その作業に関わる開発者は、 #ifdef ブロック、 configure セクション、サポート対象外のコードを削除するかもしれません。

あなたができること


もし、あなたが OS/2 または VMS のユーザだとしたら、そういったプラットフォームをサポートするためにできることは少ししかありません。
メンテナになる
活発な開発者がいるということ以上のサポートはありません。Andrew MacIntyre は、これまでかなりの期間、OS/2 のメンテナをしています。そして、彼は OS/2 は Unicode サポートに関連した Victor の当初の質問に対してはっきりと回答しました。つまり、誰かを中心にして行う必要があります。VMS は、http://www.vmspython.org を通して外部からサポートする人が現れました。しかし、 課題 11918 で議論されたように、誰かが継続された VMS サポートをアップストリームで行う必要があります。

いずれかのプラットフォームのメンテナを引き継ぐことに興味があるなら、現在の開発プロセスの 開発者ガイド を参照してください。
ビルドスレーブに貢献する
活発な開発者がいると、そのプラットフォームが生き続ける可能性が高くなります。ビルドスレーブがあれば、そのプラットフォームは何とか存続するかもしれませんが、生き残りも品質も保証されません。

Python は、継続的インテグレーションのために Buildbot を使っています。そして、Linux, Mac, Windows, Open Indiana (Solaris) における様々なバージョン、アーキテクチャ、設定のビルドスレーブが 現在、提供されています 。OS/2 または VMS のビルドの速いマシンを寄付することで、そういったプラットフォームがメインストリームのプラットフォームと同等以上のメッセージを受け取れるようになります。

もし OS/2 や VMS が生き続けられるように時間、またはハードウェアを支援できるなら、その取り組みと協調するために python-dev メーリングリストにご連絡ください。

2011年5月6日金曜日

Python Insider 翻訳プロジェクト

原文はこちら: Python Insider Translation Project

このブログのコンテンツは全世界の Python コミュニティに役立つように、なるべく多くの人たちに読んでもらえるようにすることが優先事項の1つだと考えています。私たちの取り組みをもっと拡大するために、他の言語へ翻訳したブログを作成する翻訳チームを編成しました。いま 日本語スペイン語 に翻訳されたブログが進められています。

翻訳されるには、オリジナルの Python Insider の記事が公開されてから少し時間差があるでしょうが、なるべく最新の記事が翻訳されている状態に近付けようとしています。

協力者、募集


翻訳チームはまだメンバーが少なく、協力してくれる方を募集しています。既に翻訳が進められている言語、または他の言語への展開を手伝ってくれる方を必要としています。どちらでも良いので手伝ってくれるなら、Doug Hellmann (doug dot hellmann at gmail) までご連絡ください。

2011年5月5日木曜日

チーム紹介: Brian Curtin

原文はこちら: Meet the Team: Brian Curtin

この記事は、Python コア開発チームを手短かに紹介する "チーム紹介" シリーズの1つです。

名前:Brian Curtin
所在地:イリノイ州のシカゴ
ホームページ:http://blog.briancurtin.com/

Python はどのぐらい使っていますか?

日常的に使うようになって6年になります。Python を機会に応じて大学のクラスで使うよりも前に夏のインターンシップで使っていました。

コアコミッタになってどのぐらいですか?

3月24日でちょうど1年を迎えました。

コア開発者として始めたときはどうでしたか?最初のコミットを覚えていますか?

仕事で拡張モジュールを書いているときにドキュメントのバグに気付いたのが始まりでした。それから、簡単なパッチを投稿して Georg Brandl がすぐにコミットしてくれました。そのちょっとした成功と修正されたばかりのソースコードをチェックアウトしてから、自分が使っているモジュールについてもっと深く学びたくなりました。そして、zipfile をサポートするコンテキストマネージャを追加するためのパッチを書くようになりました。

初期のコミットは、ドキュメントをシンプルにするための修正でした。最初のコードのコミットは、winreg モジュールに機能追加して、テストカバレッジを上げるものでした。

いま開発しているのは Python のどの分野ですか?

CPython の開発に関わっている数人しかいない Windows ユーザーの1人として、Windows ユーザーが遭遇する問題はどんなものでも注意を向けるようにしています。そのため、私が使っていなかったモジュールも含め多くの標準ライブラリに触れる機会がありました。私はインタープリタそのものにはあまり関わっていませんが、今後は関わりたいと考えています。

Python のコア開発を行っていないときは Python でどんなことをしますか?

C++ 言語で書かれた商取引データベースの様々なテストツールをビルドします。簡単に正規表現テスト、パフォーマンステストが書ける データ API の拡張モジュールがあり、いつもビルドばかりしています。

プログラミングをしていないときは何をしていますか?

私は熱烈な野球ファンです。春の大学野球、夏の様々なリーグの審判を務めています。シカゴ・カブスの試合観戦にも行きます。

2011年5月4日水曜日

チーム紹介: Nick Coghlan

原文はこちら: Meet the Team: Nick Coghlan

この記事は、Python コア開発チームを手短かに紹介する "チーム紹介" シリーズの1つです。

名前:Nick Coghlan
所在地:オーストラリアのブリズベン
ホームページ:http://www.boredomandlaziness.org

Python はどのぐらい使っていますか?

1999年頃、ネットワーク講座の講師が Python 1.5.2 を使っていて初めて出会いました。2002年頃から仕事で自動テストに使い始めて、その後ずっと使い続けています。

コアコミッタになってどのぐらいですか?

2005年に PEP 343 (主にコンテキストメソッドを捨てる) を更新するために Guido からコミット権をもらいました。

コア開発者として始めたときはどうでしたか?最初のコミットを覚えていますか?

パッチの提供については、2004年に3ヶ月間休んで、Raymond と Facundo と協力して decimal モジュールの、主に通信会社のベンチマークを実行して高速化する方法を見つけて、たくさんのパッチを提供しました。decimal モジュールの見知らぬ人のハック (特殊ケースを調べる高速なパスや、整数桁のタプルを整数に変換するときに文字列を利用するといったもの) は、当時に由来しています。

最初のコミットは、PEP 343 に関するものでした。その後、おそらく AST コンパイラのブランチに追加されて、2.5 に含められたはずです。

いま開発しているのは Python のどの分野ですか?

runpy, functools, contextlib が主に私の受信箱に入っています。他には、Brett と Victor がインポートでやろうとしたこと、Raymond が collections と itertools でやろうとしたこと、コンパイラに対して起こるものに注目しています。また、ものごとの文化的側面にも高い関心があります。

Python のコア開発を行っていないときは Python でどんなことをしますか?

実際にはあまりありません。仕事での Python の役割は普通に使っているだけなので、そこでハックをすることは多くありません。デジタル音楽ライブラリを整理するプログラムがとても欲しいですが、そういったスクリプトは、ちょっとしたハックですぐにできます。

プログラミングをしていないときは何をしていますか?

テコンドー、コンピュータゲーム、サッカー、読書などです。

2011年5月3日火曜日

新しいブログデザイン

原文はこちら: New Blog Design

もし Python Insider JA をフィードリーダーで読んでいるなら、 Marcin Wojtczuk が作成してくれた新しいページデザインを見ていないかもしれません。軽量な雰囲気でとても素晴らしく、この成果をとても嬉しく思います。

Marcin、時間をかけて、がんばってくれてありがとう!

2011年5月2日月曜日

urllib/urllib2 のセキュリティ脆弱性の修正

原文はこちら: urllib Security Vulnerability Fixed

Guido van Rossum は、Python の URL ライブラリのセキュリティ脆弱性である CVE-2011-1521 の 修正を最近行いました 。セキュリティ関連の問題は稀にしか起こりませんが、問題が発覚したときは、その問題の報告、対応、修正といった背後にあるプロセスをコミュニティで行ってもらう良い機会です。

問題を報告する


もし CPython 内部にあるセキュリティの問題を発見した場合、私たちが最初にお願いすることは、その問題の詳細を秘密にしておいてもらうことです。発見した問題は確かにセキュリティの脆弱性だと判断されてから、簡潔且つ詳細なレポートを作成することで、あなたの情報をコア開発者へ伝えることが重要になります。

優れたレポートは、システムの関連部分がその問題によってどのように影響を受けるかを分かりやすく説明してくれます。その問題がプラットフォーム依存、またはある依存関係のために発生するなら、その情報も同様に役に立ちます。影響のあるバージョンも分かると有益で、その脆弱性は全てのリリースバージョンで同じテストが行われます。最後に、その問題を表すテストケースを持っているなら、バグレポートに含めるようにしてください。作成されたレポートは security@python.org グループへ送られます。

Google セキュリティチームの Niels Heinen は、最近 優れたレポートを投稿しました 。彼は、標準ライブラリの urlliburllib2 モジュールの HTTP 302 リダイレクト処理に問題があると発見しました。彼が発見したのは、サーバにあるデータやシステム情報を漏洩させる可能性がある不適切なスキームでリクエストをリダイレクトできるというものでした。Neils の初期のレポートによると、こういったリダイレクト処理の問題を明らかにする2つのシナリオを説明しています。

1つ目は urllib/urllib2file:// URL スキームのためにハンドラを提供するので、 file:///etc/passwd に対するリダイレクトはパスワードファイルを漏洩させてしまいます。さらに Neils は、 file:///dev/zero のようなシステムデバイスへのリダイレクトも、サービス拒否攻撃を引き起こすリソース消費につながることを説明しました。

レポートに対応する


セキュリティレポートの機密性のために security@python.org のメーリングリストは、レポートを分析して対応できる信頼のある開発者のみの小さなグループで構成されています。このメーリングリストへのメールを暗号化したいなら、 セキュリティニュース ページの OpenPGP の詳細について参照してください。

このメーリングリストのグループが実際にセキュリティ上の脆弱性があると判断したら、修正パッチが添付された公開バグレポートが作成されることになります。今回は Guido van Rossum が、その問題があることを 課題 #11662 で公表し、初期のパッチで対応しました。

問題を修正する


Guido の修正パッチは http://, https://, ftp:// の URL スキームへのリダイレクトを制限しません。FTP のリダイレクトは、許容範囲内と考えられ、実際にダウンロードミラーシステムで、地理的に近い FTP サーバーへのリクエストをリダイレクトするときなど、一般的に利用されています。

Python 2.x では、 FancyURLopenerredirect_internal メソッドが不適切なスキームでリダイレクト処理をリクエストしようとしたときに IOError を発生させます。 HTTPRedirectHandlerhttp_error_302 も同じように動作して HTTPError を発生させます。Python 3 の urllib.request は同じ修正が行われました。その修正パッチには、有効なスキームと無効なスキーム両方のリダイレクト処理を行う2つのテストが含まれています。

この修正を受け取るユーザに関して、Python 2.5 の最後のセキュリティリリースが間もなく行われます。メンテナンスブランチ 2.6, 2.7, 3.1, 3.2 の次のパッチリリースは予定されていませんが、全てのブランチにこの脆弱性に対する修正が行われています。

2011年5月1日日曜日

チーム紹介: Tarek Ziadé

原文はこちら: Meet the Team: Tarek Ziadé

この記事は、Python コア開発チームを手短かに紹介する "チーム紹介" シリーズの1つです。

名前:Tarek Ziadé
所在地:フランスのブルゴーニュ地方ディジョン市近郊の Turcey
ホームページ:http://ziade.org

Python はどのぐらい使っていますか?

約10年です。

コアコミッタになってどのぐらいですか?

2008年12月21日になりました。

コア開発者として始めたときはどうでしたか?最初のコミットを覚えていますか?

私は Distutils のメンテナンスならびにそのツールを進化させるためにコア開発者になりました。

私のコア開発者としての最初のコミットは、コミッタになる前に自分が提案した distutils の機能の小さなバグ修正でした。それは1週間前に追加された、複数の pypi サーバで動作する upload コマンドと Distutils のレジスタを設定する Python で書かれた機能でした。

私はもらったばかりのコミット権で誕生日の2008年12月24日(水)にコミットしました。また、その日は Python 0.9.4 リリースの17周年記念の日でした。

いま開発しているのは Python のどの分野ですか?

sysconfig, distutils, packaging (3.3 に追加される), shutil, pkgutil や機会に応じてその他のライブラリも含めた標準ライブラリです。

Python のコア開発を行っていないときは Python でどんなことをしますか?

私は Mozilla のサービスチームで働いていて、Python を使ったウェブサービスを開発しています。

プログラミングをしていないときは何をしていますか?

漫画/グラフィック小説を読んだり、本を執筆したり、子どもと遊んだり、妻とワインを飲んだりします。他には1848年に建てた家を改築しようと挑戦しています。