6月リリース - 2.6.7, 2.7.2, 3.1.4

原文はこちら: June Releases - 2.6.7, 2.7.2, 3.1.4

6月は、全てのアクティブなブランチでアップデートがリリースされるという Python にとって関心の集まる月となります。

2.6.7

Python 2.6.7 はソースリリースのみですが、3つのセキュリティの脆弱性への対策が行われました。現在、2.6 系はセキュリティモードであり、これらのリリースは、基本的には必要に応じて2013年10月まで、ソースのみ提供されます。もしバイナリインストーラーが必要なら、2.7 か 3.2 へアップグレードすることを検討してください。

2.6.7 は、以前このブログで紹介した urllib の脆弱性 の対策を含んだ最初のリリースです。さらに smtpd の DoS (課題 #9129 ) と SimpleHTTPServer.list_directory の XSS (課題 #11442 ）の脆弱性も修正されています。

2.7.2

2.x 系の最後のマイナーバージョンである 2.7 は、2010年11月の 2.7.1 から 150 個以上のバグ修正が行われています。 2.7.2 のソースとバイナリインストーラーは、6月12日現在で利用できる状態にあり、2.6.7 の節で説明したセキュリティの脆弱性の修正も含まれています。

他にもたくさんのクラッシュする不具合が修正されました。例えば、別スレッドがメモリに関する変更を行ったときに Python が管理下にないメモリを不正利用してしまう不具合や、クラスから __abstractmethods__ を削除するとき、メモリマップファイルへ更新前のファイル長でアクセスしてしまうことなど、その他にもいくつか修正されました。

getpass のある修正が、CTRL-C と CTRL-Z の扱いに関してリグレッションを引き起こしていた問題が修正されました。 multiprocessing は、実行中に固まったような Windows サービスの扱いと multiprocessing.Pool ワーカーの終了時の競合状態への修正を含めた、たくさんの修正が行われています。 mmap は、 32 ビットビルドでも 4GB 以上のファイルサイズとオフセットを扱えるように修正されました。また、書き込みできないマップファイルへ書き込もうとしたときに、セグメンテーションフォールトではなく TypeError を発生させるようになりました。

全ての変更内容については 2.7.2 NEWS ファイル をご覧ください。

3.1.4

3.1.4 は 3.1.x 系の最後のバグ修正リリースです。3.2 へ移行するにつれて 3.1 はセキュリティモードに入ります。3.1.4 は2010年11月の 3.1.3 リリースから 100 個以上のバグ修正を含みます。2.7.2 と同様に、バイナリインストーラーが6月12日現在で利用できます。3.1.4 は、2.6.7 で説明したセキュリティ脆弱性の修正を含む最初の 3.x 系のリリースです。

3.1.4 は、オブジェクトを調べる __dir__ に関するいくつかの問題や、 os.stat と os.utime の Windows 環境の実装における2038年以降の日付の問題、たくさんの 64 ビットのクリーンアップの問題を修正しました。 io ライブラリは、データが読み込めなくて、他の場所で適切な例外が発生したときに None を返す変更がたくさん見られます。64 ビット Windows 環境での ctypes のコールバック引数が修正されて、クラッシュしないように改善されました。

全ての変更内容については 3.1.4 NEWS ファイル をご覧ください。

3.2.1

3.2.1 は、現在、リリース候補 (RC) の段階です。RC1 は既に完了し、すぐに RC2 がリリースされるでしょう。私たちは、ユーザが発見したどのような不具合にも対応できるように、3.2 RC を実際に試してくれる方へとても感謝しています。もしバグを発見したら bugs.python.org へ登録するようにしてください。

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