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

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

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

貢献者の募集

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

早期の成功

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

行動規範

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

参加表明

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

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

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

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

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 は、ロックのタイムアウトをもつスレッドを使うのに対して、サードパーティモジュールは SIGALRM と alarm() を使います。

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

早期の成功

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

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

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

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

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 のビルドを手伝ったりするのがもっと簡単になります！

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 メーリングリストにご連絡ください。

Python Insider 翻訳プロジェクト

原文はこちら: Python Insider Translation Project

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

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

協力者、募集

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