Python Insider JA

2012 言語サミットレポート

2012-04-07T12:45:00.003+09:00

原文はこちら: 2012 Language Summit Report

今年の言語サミットは、 PyCon 2012 が開催される前にカリフォルニアのサンタクララで3月7日(水)に開催されました。前年と同様に、様々な Python VM やコミュニティプロジェクトの開発者、Linux ディストリビューションのパッケージャーが出席しました。

名前空間の PEP

サミットは Barry Warsaw の進行のもと、PEP 382 と 402 の議論から始まりました。少し議論を行った後、その2つの PEP の一部分のために求められているものに関して、最終的にその決定は延期されました。

月曜日の PyCon スプリントで、その2つの PEP は却下されました (それぞれの PEP の上部に却下されたことが明記されています) 。Martin von Loewis は、その解決方法が見つかったと import-sig メーリングリストへ投稿しました。そして Eric Smith がそのメーリングリスト上で合意された内容を新たな PEP として草稿を作成する予定です。事実上 PEP 382 は完全に却下されましたが、PEP 402 の一部分は承認されることでしょう。

`importlib` の状況

Brett Cannon は http://hg.python.org/sandbox/bcannon/ から importlib を使う CPython のブランチが利用できるようになったと発表しました。 bootstrap_importlib という名前付きブランチを確認してください。

既に存在する課題のみを要点にして議論が始まりました。その課題はディレクトリの stat を行うときに発生し、時間の精度に関するマイナーな後方非互換の課題です。しかし、全員がそのことは致命的な問題を起こすようには思えないので、その作業を進捗させることで合意しました。さらに stat 呼び出し周りで最適化も行われました。この最適化は、Brett, Antoine Pitrou, P.J. Eby が自主的に行ったものでした。

パフォーマンスの話題が持ちあがり、Brett は現在のピュア Python 実装は約 5% 遅くなると説明しました。Thomas Wouters は、5% 遅くなることは実際には良いことだと大きな声で言いました。特に彼が行っていた最近のベンチマークについて、何度かコンパイラを変更して起動時に 5% 違うことを紹介しながら説明しました。この 5% 遅くなることは、そのコードのインテグレーションを遅らせるものではないという認識が共有され、議論は良い方向に進みました。

Brett がそのブートストラップが実際にどういったものであるかを説明しました。そしてまだ、その実装が、最初の 現実の フリーズされたモジュール (frozen module) の利用方法になるか調べて検証しているところだと続けました。Guido の最初の返答はこうでした。"最終的にそのフリーズされたコードの利用方法を見つけたと20年後に言うの？"

importlib._bootstrap は、少しの関数の再実装に加え、処理に必要な組み込み関数を含むフリーズされたモジュールです。そのフリーズされたモジュールを含むライブラリは、 warnings, _os (posix からのコード), marshal です。

また別の互換性の問題がありましたが、この問題も先ほどと同じように進捗を妨げるような類いの問題ではないという結論になりました。 importlib で対応しない負のレベル数があります。それは暗黙の相対インポートで使われていますが、対応せずにこのまま継続することで合意しました。

今後は import.c の機能を分解していくことになりそうです。多くの importlib API の公開と同様に、多数のフックを公開します。

default ブランチへのマージに関しては、これは 3.3 に向けて行うべきだとかなり幅広い合意が得られました。そして、アルファとベータサイクルを通して、その実装のマイレージを取得するためにすぐ行われます。そう間をおかずに行われた後に、Brett は python-dev で詳細を整理して、レビュー内容を見直す予定です。

リリーススケジュール PEP

PEP 407 と 413 は importlib の議論に続くものでした。名前空間 PEP の議論のように、アイディアは出ましたが、そのグループは PEP の承認について結論に至りませんでした。

すぐに2つの PEP と結びつく標準ライブラリを分割して独自ライブラリにするアイディアが復活しました。しかし、テストスィートがどこに置かれるのかという疑問が残りました。さらに、標準ライブラリを取り扱うテストと、言語機能を取り扱うテスト間で区別する必要があるかもしれません。

3つのバージョンが必要になるというバージョン管理の話題が持ちあがりました。それらは言語仕様バージョン、その実装バージョン、標準ライブラリバージョンの3つが必要になると思われます。

多くのコメンテーターが、このような PEP はあまりに複雑過ぎると指摘しました。さらに、こういった変更のうちどれかに注意を払うユーザーが実際にいるのかという疑問もありました。我々のうち数人は「 私たち ならより素早いリリースのために使う」と明言しましたが、多くのユーザーは何らかの理由で古いバージョンか、他のものをずっと使うでしょう。つまり、誰がそのリリースを使うことになるか疑問に思いました。

Thomas Wouters は、類似の LTS スタイルのリリースを行う Python コンシューマーで Python "LTS" リリースのラインアップの難しさについて良い点を突きました。Ubuntu とその LTS スケジュールは主要な例です。Ubuntu のような何かのプラットフォーム上で動くリリースを計画する組織も同様です。出席していた多くの Linux ディストリビューションのパッケージャーが頷いているようでした。

広く合意を得られたことの1つに、標準ライブラリのリリースサイクルを短くすることは、新たな貢献者にとっては良いことだということです。新たな機能追加に興味をもつ開発者からみて、一年以上に渡ってリリースしないというのはおもしろくありません。バグ修正を行ったとしても、時にはそのリリース期間があまりに長くなってしまうかもしれません。そのリリース時期というのは、可能な場合にユーザーが自分たちのコード内で我々の問題を修正してしまうところです。

Guido は、"自分のパッケージが標準ライブラリに含められるほどには認められていない" という考えをもたないようにする方法についてコメントを続けました。その要点は、PyPI 上でホストされている1つのプロジェクトであり続けることです。現実の世界で成功を収め、そのプロジェクトと API 群が成熟してから標準ライブラリへの追加を慎重に議論します。

素早いバグ修正リリースはおそらくは良いことだと提案されました。しかし、そのパッケージの開発者たちが、より頻繁なリリースを行うために労力を惜しまず動いてくれるかを保証するため、我々はリリースマネージャーと共に確認する必要があります。その新たな機能リリースと同様、新たなバグ修正を行ったものを使うユーザーがいることも確認しなければなりません。

また、以前の "sumo" というリリースに関する議論も行われました。そういった類いのリリースは、既にサードパーティーベンダーが行っています。このアイディアは大きな推進力を得るようには思えませんでした。

Python ソフトウェア財団からの資金

PSF 会長の Steve Holden は、財団は開発への取り組みを支援するのに使えるリソースがあることを言うため、ランチの後からそのグループへ参加しました。それは特に今年のカンファレンスのスポンサーシップの成功によるものです。財団は何をコーディングするかを規定できないし、規定することもありませんが、資金提供が必要な種類の作業についての提案は常に受け入れています。

Steve と Jesse Noller は、全ての Python 実装だけでなく、サードパーティーのプロジェクトに向けても支援することに強い意志をもっていました。あるプロジェクトが資金提供を受けるのに必要なことは、そこで成し遂げられるものへの具体的な提案です。彼らは資金提供の準備は整っているのに、それが待ち状態であることにストレスを感じていました。つまり提案することは、その待ち状態を解除する手段です。

資金提供のアイディアのいくつかは Steave からのものでしたが、会場内からも出ました。1つのアイディアとして、1ヶ月休職するのに資金提供するという議論がありました。そして、それは誰ができるかという問題がありました。何人かは、開発コミュニティにいるフリーランスのコンサルタントが雇いたい開発者になるかもしれないと提案しました。こういったフルタイムの雇用は、実際に長期休暇を取得するのが難しいという結論になるかもしれませんが、誰にでもその可能性はあります。

別のアイディアでは、フルタイムでバグトラッカーを見てその流れを良くする誰かに、理想的には既にそういった選定作業を行ってくれている人に資金提供する可能性について話しました。この種の資金提供の意図は、バグ修正は3日で完了したのに、そのパッチが取り込まれるのに3年かかるようなことを止めたいというものです。これは短期的に素晴らしいアイディアだと思う人がいましたが、その作業は大変な労力を伴い、それを行う個々人は燃え尽きてしまう可能性が考えられます。誰かやりたい人がいれば、財団へそのアイディアを提案することをお奨めします。

トラッカーのメンテナンスと類似の内容で、Twisted プロジェクトの Glyph Lefkowitz は、コーディング後のコードレビューの取り組みに資金提供するアイディアを出しました。これは regex/re の状況を前へ進める良いアイディアだと推す人もいました。 regex はとても巨大で、標準ライブラリへの追加の障害となっている唯一のことは徹底的なレビューだと多くの人が感じています。 cdecimal モジュールもレビューの補助が必要な別プロジェクトだという指摘もありました。

コードレビューへの資金提供は、サードパーティプロジェクトの Python 3 への移行を推進するアイディアの1つでもあります。特に言えば Twsited プロジェクトで、その開発者たちは資金提供を受けるような労力があることを感じていました。
ここに至りコアメンターグループは、新たな貢献者を取り込むのに成功していることを述べました。このことへの賛辞は、そのメーリングリストで行われています。

`virtualenv` の追加

約2分間、PEP 405 の議論が行われました。Carl Meyer は、参照実装は利用できる状態になっていて、ちゃんと動いていると述べました。Mac OS X のメンテナーから見ても有益であり、Ned Deily と Ronald Oussoren の2人ともそこに出席していました。PEP の残り作業はあと1つだけで、その宣言を行う誰かを見つけることです。そして Nick Coghlan がやらないのならと、Thomas Wouters が自分の名前をそこに追加しました (Nick は PEP の第一人者となるでしょう) 。

PEP 397 の追加

このサミットで Windows 表現はあまりなく、議論はすぐに終わりましたが、我々が承認すべき PEP 397 がどうようなものかに多くの合意が行われました。Brian Curtin は、この PEP に賛成して、実行可能なディレクトリを選択的に追加するために Windows インストーラーの進捗中の作業についても話しました。

このサミットとは違う場での議論により、追加でこのランチャーが Python 3.3 Windows インストーラーでインストールされることが合意されました。その一方で、ランチャーをインストールしない独立したインストーラーとしても使えます。さらに、実装についての制約があまりにも細かい多くの低レベルな詳細を削除するという作業が PEP に行われます。例えば py.ini ファイルの配置の説明がそうです。

speed.python.org

気前の良いハードウェアの寄付により http://speed.python.org のサイトが構築され、いまは PyPy のベンチマークに使われています。我々は、Python 3 スイートを作成するときにどんなベンチマークを 使うべき かと同様に、どんなベンチマークが使われるかを決める必要があります。Python 3 の実装が増える毎に 2.7 のテスト規模を縮小して、3.x を推進していきます。

このプロジェクトは、技術的な問題ではなく人の問題に悩まされています。それは資金提供が行われる別の場所があると考えられました。しかし、お金があったとしても、時間、ノウハウ、タスクを完全に掌握できる人物をこれから探す必要があります。理想的には、最初のタスクは PyPy と CPython 実装の実行と比較を行います。その後、たくさんのインフラをラインに乗せます。

PEP 411 の追加

PEP 411 は、標準ライブラリに暫定的なパッケージを含めることを提案します。最近、論議された regex と ipaddr モジュールは、この PEP に含まれるライブラリの例です。この標準ライブラリへの追加をどう実装してユーザーへ提示するかが主な論点となりました。

最初の提案は、ドキュメントのノートだとうまくいかないということでした。ドキュメントはユーザーへ通知する1つの手段であり、それのみに頼っているわけではありません。特に今回のようなコードを追加するような種類のものに対してはそうです。ライブラリ上に実験的な状態を示すフラグを設けるという提案もありました。別の提案で暫定的なライブラリのインポート時に警告を表示するというのもありました。しかし、開発者が警告を有効にしてテストスイートを実行することを想定すると、ユーザーコードに影響を与えないように、デフォルトでは表示したくないということも考えられます。また一方で、我々が何度も経験してきたように、そういった警告をうっとうしく思い、全ての警告を無効にしてしまう開発者がいるというリスクがあります。

python-dev では、特別なパッケージから暫定的なパッケージをインポートするのが提案されています。例えば from __experimental__ import foo です。この提案はかなり強く推奨されました。そのライブラリが一貫した API を備えている場合、暫定的な状態から公式に承認された状態に移行したときにユーザーには不都合があります。エイリアスは単純に問題を悪化させるだけです。

PEP はプロセスについてどうあるかを要約します。そして、我々は追加されるライブラリが API の変更機能を使えるように保証する必要があります。また、幅広くユーザーに使われるコードのように変更を受け入れて、フィードバックに責任をもつ人たち、特にライブラリ作者を育てる必要もあります。

振り返ってみて、Jesse Noller は multiprocessing がこの PEP が提案しているものの良い候補だと提案しました。このときになって、Michael Foord の mock を暫定的に unittest に、おそらくは unittest.mock として追加することが提案されました。その代わりに mock の安定した API と、我々が自分たちのテストスイート内でモックライブラリの必要に応じてよく使うものは、暫定的な状態を経ずに標準ライブラリへ直接追加するのが妥当だと合意を得ました。

PEP 内の regex の役割の話題の中で、 regex は暫定的な状態を迂回して標準ライブラリへ導入するという Thomas Wouters のアイディアがありました。そして既存の re モジュールを sre という名前に移動します。その場では反対意見はありませんでした。

そのライブラリのメンテナーは細心の注意を払い、API の変更についてかなり保守的にならないといけないという暫定的なライブラリのユーザーへも注意が必要です。我々が最もやりたくないことは、優れたライブラリのユーザーを動く標的にして、そのライブラリを導入することです。

全ての組み込み関数でのキーワード引数

最近、トラッカー上に API に対してキーワード引数をより広く使われるのが良いという提案がありました。Gregory P. Smith は、1つの引数を取る API はそのままにしておき、それ以上の引数を取る API については賛成しました。しかし、全般的な変更は "変更の目的や利点を変えてしまう" ものとして先送りされました。

この変更を行うために、 PyArg_ParseTuple 関数はより多くの処理を行う必要があり、そうすると遅くなることが既に分かっています。もう1つの方法として PyArg_Parse を使うと遥かに速いです。そのタプルバージョンは、組み込み関数のどのような変更にも関係なく、そこから1つか2つの引数を受け取ります。

組み込み関数を Python のものに置き換えるときに潜在的に互換性を壊してしまう箇所があります。それは、位置引数のみを受け取るときに潜在的に名前が競合するところがあります。

それは任意のブラケットルールを避けて、大掛かりな変更を行うよりも理にかなっているところの変更を維持することで広く合意されました。また我々は、実際のキーワード引数名に一致するように doc string を維持しておき、それらを一致させておくのと同様にドキュメントに留意する必要があります。

OrderedDict がキーワード引数のためのコンテナとして提案されました。しかし、Guido と Gregory はその使用例について不確かな様子でした。我々は、普通のディクショナリか、または順序付きディクショナリを使うかどうか、場合によっては、これらを処理するデコレーターを使うというのも提案されました。Python レベルの関数として PyArg_ParseTuple のような何かを公開するというところまで進みました。

関数シグネチャオブジェクトに関する PEP 362 は、一般にデコレーターで使われ、ここで役立ちます。残っている作業はその PEP をもう一度見直して、誰かが定義することだけにみえます。

Python 3 への移行

次に Python 3 移行の話し合いに移りました。現在の戦略と、どうやればうまくいくのかというところから始まりました。単一コードベースの移行は、2.4 のバージョンをサポートする場合 except の扱いがちょっと厄介ですが、多くの人たちにとって期待されたものよりうまくいっています。多くの選択肢があり、3to2 や 2to3、並行ツリーの単一コードベース、といった方法が本当に良いものです。しかし、プロジェクトの戦略を選択するのが難しくて、うまくいっていません。それが大半のドキュメントが数多くの戦略について記載されている理由です。

移行ドキュメントに現実の世界の移行例をもっと紹介することが提案されました。理想的には、こういったプロジェクトのチェンジセットの移行についてです。クックブックスタイルのアプローチを取っている我々の移行ドキュメントは、良いアイディアだと支持する人もいました。

ハッシュの疑似乱数

セキュリティの修正を行った全てのブランチでリリース候補 (RC) が利用できます。一方 David Malcolm は、アップストリームの expat プロジェクトにあるセキュリティの修正を報告しました。しかし、アップストリームは同時にその他の修正も一緒に含めていたので、今回はセキュリティの修正のみを適用し、その他のバグ修正は一旦置いておき、関連ブランチの次のバグ修正リリースで行います。

新しい `dict` 実装

実装は理にかなっているしテストも通ったので、Mark Shannon の PEP 412 は承認されるものとすぐに合意を得ました。このサミットで合意されたその他の変更に関して、アルファとベータサイクルを通して、そのマイレージを取得するために、その変更はすぐに push されると思います。この承認により、コードをメンテナンスできるよう Mark にコミット権が与えられました。

また、この実装はソート順序の違いをもたらすというユーザーに見える違いだけでなく、最近のハッシュのランダム化作業はこのことを問題点としているということも述べました。

新しい `pickle` プロトコル

Lukasz Langa が提案した PEP 3154 は、新しい pickle プロトコル (バージョン4) の仕様です。Lukasz は multiprocessing の例外を pickle 化するのに課題があると指摘して、Antoine がその課題を解決しました。修飾された名前が役に立つ一方で、この PEP はもっと関心を払う必要があると合意されました。

質問やコメントがあれば python-dev へ投稿してください。
この記事は Eric Snow と Senthil Kumaran が投稿してくれました。ありがとう

チーム紹介: Brett Cannon

2011-08-28T12:00:00.000+09:00

原文はこちら: Meet the Team: Brett Cannon

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

名前:	Brett Cannon
所在地:	アメリカ、カリフォルニア州のサンフランシスコ
ホームページ:	https://profiles.google.com/bcannon
ブログ:	http://sayspy.blogspot.com

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

2000年の秋から使っています。

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

2003年4月になりました (PyCon 2003 のすぐ後です) 。

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

パッチをコミットするときにバグを混入させてしまう人たちは必ずいるので、私はコア開発者になれました (その仕掛けは 2003/2004 年の Python 人気が急上昇して目立つようになる前にコミット権をもっていた人たちが行っていた管理方法がうまくいかなくなったからです) 。2002年8月から始めて、私は Python-Dev Summaries を活発に行っていました (これは約2.5年間も続きました) 。Python-Dev Summaries を書いていたとき、私は修正が必要な小さな課題を定期的に、且つ公正に拾いあげていました。

私の最初のコミット (チェンジセット 28686）は、time.strptime() の文字列のエスケープに関する修正でした (そのコミットが Python への私の最初の貢献になったのはたまたまです) 。

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

普段、私はインポートの仕組みと Python の言語が全ての VM 上でうまく動作するように作業しています。

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

私は、Python でサーバー側の機能を実装して、自分の博士論文の管理に使っています。その他には、個人的なプロジェクトにできるだけ Python を使っています。将来の Google での仕事は、主に Python を使うつもりです。

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

私は TV で放送している映画のちょっとしたマニアです (2000年の夏の猛暑のときにテレビを失ったことは、偶然起こった最も良いことでした。それは妻と結婚したことであり、私が目的をもって行動した最良の出来事でした。TV を見ないときは、たくさん読書をします。主に雑誌やウェブサイトですが、常に何冊かの本を読みかけ状態です。

チーム紹介: Michael Foord

2011-08-13T18:30:00.002+09:00

原文はこちら: Meet the Team: Michael Foord

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

名前:	Michael Foord
所在地:	イギリスのノーサンプトン
ホームページ:	http://www.voidspace.org.uk/

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

私は2002年に趣味として Python を使い始めました。その後、2006年から仕事においても Python を使うようになりました。私が Python でプログラミングを始めたきっかけは、電子メールのゲームでそのゲーム情報を集計するプログラムを書いたチームと一緒に開発したことでした。私たちの誰もしばらくそのプログラムを完成できずにいて、たまたま SmallTalk を使うことが決定していました。あるとき、誰かが Python を試してみようと提案し、私はすぐに Python と恋に落ちてしまいました。

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

私は2009年の PyCon でコアコミッターになりました。もともとは IronPython との関連があったからです。

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

PyCon 2009 のスプリントの期間中、Google が提供した unittest に対する改善を取り込むために Gregory Smith やその他のコア開発者たちと一緒に開発をしました。

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

PyCon スプリントでの unittest の初作業後も、メンテナーが不在だった unittest の課題の修正や改善を行っています。私は unittest のメンテナーだけでなく、他の標準ライブラリにも貢献しています。

その他に様々なマイナーな方法で Python をサポートすることに関与しています。例えば、Planet Python をメンテナンスしたり、PSF メンバーになったり、python.org のウェブマスターを手伝ったりしています。

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

私の日々の仕事は、Canonical 社のウェブ開発です。私は、Canonical 社のウェブサイトに関するウェブサービスインフラの作業をしていて、Ubuntu と結びついたサービスにも携わっています。それは楽しい仕事ですし、チームも素晴らしいです。

時間の空いたときに、 unittest2 (その他のプラットフォーム向けに unittest の改善のバックポート)、 mock (モックオブジェクトを提供してテスト中にモンキーパッチをサポートするテストライブラリ)、その他の多くの機能に関するプロジェクトに取り組みます。

私はもっとコーディングしたいのですが、IronPython in Action という書籍を書くために2年間の大半をかけて専念したことにより、すぐに大規模なプロジェクトには関わらないように考えています。

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

私はノーサンプトン (イギリス) の教会に関わっていて、かなり多くの時間を割いて、自分たちが行うチャリティの管理を手伝っています。これは、なぜ Canonical 社で働くのが良いかという理由の1つです。私は自宅で仕事ができて、この街に根をおろし、どこへも行きたくありません (気候があわないところは住めない) 。言うまでもなく、ノーサンプトンでは Python プログラミングがあまり活発ではありません。私の最初のプログラミングの仕事は、ロンドンの素晴らしいチームと一緒に行ったもので、自宅を出てから職場まで通勤に片道2時間かかりました。4年間の通勤をやり繰りしました。その仕事は本当に楽しいものでしたが、通勤から逃れられるなら私は戻りたくありません。

さらに私は XBox 向けのゲームをします。不運にも好きなゲームを見つけてしまったときは、何週間もそのゲームに引き込まれるので私は注意するようにしています。この理由のために World of Warcraft や EVE Online といったゲームはしないようにしています。また、毎月のノーサンプトンのギークミーティングの運営も行っています。そこには Python ユーザーグループの Python プログラマーはあまりいませんが、あらゆる類いの優れたギークたちが集まります。普通は、ただパブに集まって気軽に話したり、自分たちの最新のガジェットを披露します。

Windows 向け Python ランチャー

2011-07-12T07:15:00.000+09:00

原文はこちら: A Python Launcher For Windows

Mark Hammond (pywin32 の作者であり、長い間 Windows 環境の Python サポーター) は、 PEP 397 を提案しました。その PEP は Windows 環境の新たな Python ランチャーについて記述したものです。Vinay Sanjip (標準ライブラリ logging モジュールの作者) は、つい先日そのランチャーを実装して、いま https://bitbucket.org/vinay.sajip/pylauncher/downloads からダウンロードできます。

このランチャーは、Python 2 と 3 が同時に利用可能であり、Windows 環境の Python スクリプト (.py と .pyw ファイル) に対して、実行する Python のバージョンを指定します。

Windows ユーザーは、残っている問題を解決する Python 開発者を支援するために、このランチャーをダウンロードしてテストすることを検討してください。このランチャーは、独立したアプリケーションとしてパッケージングされていて、現在、利用できる Python のバージョンをサポートします。目的としては、ランチャーが完成したら、Python 3.3 の一部として提供する予定です。(依然として、以前のバージョンのユーザー向けに独立したアプリケーションとして利用できるようにする予定ではあります)

このランチャーは2つのバージョンが利用できます。 Program Files ディレクトリにインストールする launcher.msi と、Windows の System32 ディレクトリにインストールする launchsys.msi です (64 ビット Windows 向けの 64 ビットバージョンも用意されています) 。

ランチャーについての詳細

ランチャーの動作についての完全な仕様は PEP 397 に記述されています。次に基本的な原則をまとめます。

ランチャーは、 py.exe (コンソールバージョン) と pyw.exe (GUI バージョン) の2つの実行可能ファイルを提供する。
ランチャーは、 .py (コンソール) と .pyw (GUI) の拡張子をもつファイルのハンドラとして登録される。
スクリプトを実行すると、ランチャーは Unix スタイルの #! (シェバング) を探す。そして python (システムデフォルトの Python)、 python2 (デフォルトの Python 2 リリース)、 python3 (デフォルトの Python 3 リリース) の実行可能ファイルを認識する。このバージョン指定の詳細レベルは、ユーザまたはマシン毎に簡単に変更できる。
独立して使う場合、 py.exe コマンドランチャーは Python 対話型インタープリターを起動する。次の用途にコマンドラインスイッチがサポートされる。 py -2 が Python 2 を、 py -3 が Python 3 を、 py がデフォルトバージョンを起動する。

シンプルな使い方

ランチャーをインストールすると、 .py と .pyw スクリプトファイルが関連付けされます。他に自分で設定しない限り、スクリプトはシステム上のデフォルトの Python を使って実行されます。そのため、特に変更は見られません。もしコンソールをよく使うなら、1つだけ設定を行った方が良いかもしれません。それは PATHEXT 環境変数に .py を追加することで、スクリプトが別のコンソールで実行されないようにします。

Python 2 を使う必要があるスクリプトを指定するには、単に次の1行を

#!/usr/bin/env python2

そのスクリプトの最初の行に追加してください。(これは Unix 互換な書き方ですが、Unix 互換を必要としない場合は #!python2 でも構いません) 。

一方、Python 3 を使う必要があるスクリプトを指定したいなら、次の1行を最初の行に追加してください。

#!/usr/bin/env python3

また次のいずれかのコマンドを使って、Python インタープリターを起動できます。

# Python のデフォルトバージョン
py
# Python 2
py -2
# Python 3
py -3

実行するには、 py.exe の実行可能ファイルのパスが通っている必要があります。これはインストーラーの launchsys バージョンでは自動的に追加されますが、 launcher.msi のバージョンでは PATH に対して手動でインストールディレクトリ (C:\Program Files\Python Launcher) を追加する必要があります。

参考文献

次に紹介する python-dev メーリングリストのスレッドで重要な議論が行われています。

Mark による最初の PEP 草稿の発表: http://mail.python.org/pipermail/python-dev/2011-March/109509.html
PEP 草稿の第2版: http://mail.python.org/pipermail/python-dev/2011-March/109786.html
ランチャーの C 実装についての Vinay の最初の質問: http://mail.python.org/pipermail/python-dev/2011-June/112145.html
Vinay による C 実装の発表: http://mail.python.org/pipermail/python-dev/2011-July/112184.html
Vinay によるテストの呼びかけ: http://mail.python.org/pipermail/python-dev/2011-July/112251.html

CPython 3.2.1 リリース

2011-07-12T06:00:00.002+09:00

原文はこちら: CPython 3.2.1 Released

python-dev チームを代表して、リリースマネージャーを務める Georg Brandl は CPython 3.2.1 の最終リリースを発表しました。Windows インストーラーと tar ボールが7月10日に提供されています。ぜひ、このリリースへアップグレードを検討してください。

What's New ドキュメントに 3.2 の新機能一覧が、ソースファイルに含まれる Misc/NEWS ファイルにバグ修正の一覧があります。

このリリースに関する問題、または何か他に問題を見つけたら http://bugs.python.org/ へ報告してください。

3.2.1 RC2 リリース

2011-07-07T10:30:00.000+09:00

原文はこちら: 3.2.1 Release Candidate 2 Released

6月リリースに続いて、3.2.1 系の2番目のリリース候補 (RC2) が提供されています。5月15日にリリースされた最初のリリース候補から、40以上の問題を修正しました。3.2.1 の正式リリース前にもう1度確認する意味も含めて、みなさんのプロジェクトでこの RC2 をテストするのをお奨めします。

修正箇所

I/O

#1195 は修正するのに2、3年かかりましたが、 fgets を呼び出す前に clearerr を行うシンプルな修正により、 input() 内部で CTRL-D による sys.stdin.read() の中断に関する問題を解決しました。 io システムは、 #12175 において、 read() が None を返すときに、その返り値の None と共に readall メソッドでクリーンアップするようにしました。そして、ファイルが開けないときは ValueError を発生させます。

#11272 は、RC2 で行われた修正内容ではありませんが、3.2.1 の重要な修正内容で、Windows 環境での文字列の後ろに続く \r に関する input() の修正です。この問題は何度も報告され、多くの人に影響を与えていました (disutils の upload コマンドなど) 。3.2.1 がうまく解決してくれることを望みます。

Windows

3.2.0 は、Windows 向けに os.symlink という新機能を追加しました。この機能は #12084 の問題からきていて、 os.stat は、Windows のシンボリックリンクを間違って評価するので、内部の様々な stat 関数の仕組みが修正されました。

あるユーザーが os.path.isdir が遅いことに気付きました。この原因は、前述した os.stat の修正によるもので、特にシンボリックリンクを評価するときに通常ファイルより2倍遅くなっていました。 os.path.isdir は、パフォーマンスのボトルネックにはならないとはいえ、インタープリター上で何度も呼び出されます。 GetFileAttributes を使う #11583 の修正により、ほんの少しだけ高速化されます。

subprocess

誤った引数で Popen オブジェクトを作成すると AttributeError が発生していましたが、その問題は #12085 で報告され、その報告者が修正しました。3.2.0 での変更に伴い、環境変数が空のとき、特に env 引数を Popen は正しく扱っていませんでした。 #12383 でその問題が報告され、すぐに修正されました。

その他

3.2.1 RC2 の全ての変更内容を知りたい方は、チェンジログをチェックアウトしていますぐダウンロードしてください！

いつものように、どんな問題でも http://bugs.python.org へ見つけた問題を報告してください。私たちは、みんなの協力により品質の高い Python をリリースできることに感謝しています。

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

2011-06-15T00:15:00.000+09:00

原文はこちら: 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 コアメンターシッププログラム

2011-05-24T17:30:00.002+09:00

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

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

貢献者の募集

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

早期の成功

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

行動規範

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

参加表明

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

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

2011-05-20T01:15:00.000+09:00

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

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

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

2011-05-14T10:07:00.001+09:00

原文はこちら: 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 の競合状態を追跡するのに役立っています。このモジュールがあなたのプログラムにおいても役立つことを願っています。

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

2011-05-09T22:00:00.004+09:00

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

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

Jython リポジトリを Mercurial へ移行

2011-05-08T13:00:00.003+09:00

原文はこちら: 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 のサポート終了へ

2011-05-07T08:00:00.014+09:00

原文はこちら: 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 翻訳プロジェクト

2011-05-06T08:00:00.001+09:00

原文はこちら: Python Insider Translation Project

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

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

協力者、募集

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

チーム紹介: Brian Curtin

2011-05-05T08:00:00.001+09:00

原文はこちら: 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 の拡張モジュールがあり、いつもビルドばかりしています。

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

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

チーム紹介: Nick Coghlan

2011-05-04T08:00:00.002+09:00

原文はこちら: 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-05-03T08:00:00.001+09:00

原文はこちら: New Blog Design

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

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

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

2011-05-02T08:00:00.001+09:00

原文はこちら: urllib Security Vulnerability Fixed

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

問題を報告する

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

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

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

1つ目は urllib/urllib2 は file:// 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 では、 FancyURLopener の redirect_internal メソッドが不適切なスキームでリダイレクト処理をリクエストしようとしたときに IOError を発生させます。 HTTPRedirectHandler の http_error_302 も同じように動作して HTTPError を発生させます。Python 3 の urllib.request は同じ修正が行われました。その修正パッチには、有効なスキームと無効なスキーム両方のリダイレクト処理を行う2つのテストが含まれています。

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

チーム紹介: Tarek Ziadé

2011-05-01T08:00:00.002+09:00

原文はこちら: 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年に建てた家を改築しようと挑戦しています。

AST (抽象構文木) の変更管理ポリシーの策定

2011-04-30T08:00:00.002+09:00

原文はこちら: Formalizing the AST Change Control Policy

Python は、 AST モジュールを使用して、ソースコードをコンパイルした形で表現される AST (抽象構文木) を見えるようにしています。AST モジュールを使用すると、ソースコードを構文解析してバイトコードにコンパイルされる途中の過程で、ユーザが AST で表現されたものを操作したり検査したりできます。

Python コードの構文や意味論は、言語リファレンスで定義されていますが、AST モジュールは、CPython の実装における詳細であり、他の Python 実装で実装される必要があるわけではありません。

AST の互換性

(これまでのところ、raw バイトコードというより) AST で動作する CPython オプティマイザを書き直す作業の一環として、Eugene Toder は AST の構造を変更する必要がありました。CPython の実装のように、後方互換性のポリシーが AST に適用されるものかどうか、すぐに分からないので、Eugene は python-dev で質問しました。AST が変更されるときに後方互換性を保証する必要はありますか？

その互換性は 必要ない という合意になりました。AST モジュールには定数 ast.__version__ があります。これは使用する AST のバージョンに依存してその動作が変わることをユーザへ伝えるコードです。実装に特化したモジュールにとってはこの情報が十分な互換性と考えられました。

他の Python の実装

実際の事実として、Jython と IronPython 双方のメンテナは、彼らのプロジェクトのそれぞれの実装も AST モジュール、またはその機能を提供するモジュールと互換性があることを指摘しました。たとえそうでも、彼らはそのことから AST モジュールを凍結すべきだという考えではありませんでした。そして、AST が互換性のない方法で変更されても ast.__version__ という定数も変更されるのであれば十分だと考えています。

議論になったポイントの1つは、他の実装の AST 表現が CPython と互換性があることを保証するのに便利な test_ast.py のテスト一式です。 test_ast.py のカバレッジを上げることは、Python の内部構造に関わりたい人にとって良いプロジェクトになります！

この後どうなるの？

議論を起こしたパッチはまだ CPython に取り込まれていません。そのため、しばらくは何も起きません。しかし、そのパッチがコミットされると、AST は互換性のない方法で変更する予定です。 ast.__version__ 定数は、このことを反映して変更します。そのため、ユーザコードでも分かりますが、変更が必要になります。一般的にこの内容は将来的に AST の変更を扱う方法になるでしょう。

Python の開発者は、AST がどのぐらい広く使われているか、このポリシーの変更がどのぐらい影響するのかに関心があります。もし、この変更が影響を及ぼすコードをもったユーザがいたら、 python-dev の議論に参加されることをお奨めします。

Thomas Heller が ctypes メンテナを辞任

2011-04-29T08:00:00.003+09:00

原文はこちら: Thomas Heller Steps Down as ctypes Maintainer

Python の開発コミュニティは ctypes メンテナである Thomas Heller から長い間、恩恵を受けています。今月の初め、Thomas は Python 2.5 以来、彼のホームであった CPython プロジェクトの ctypes から去ることを発表しました。

私は Thomas と話す機会があり、彼が Python と共に歩んだ歴史と参加した ctypes と py2exe プロジェクトについて尋ねてきました。

Python

1999年に遡ります。Thomas は、Python を学ぶための情報源を探していたところ Mark Lutz の Programming Python を手に入れて、すぐにその言語に夢中になりました。彼は Windows 向けに書いた巨大な C 言語のプログラムの拡張言語として Scheme に置き換えている途中でした。

彼が開発チームに加わった経緯について、彼の最初の CPython (そして、オープンソース一般) への貢献は、 distutils に対する Windows 関連の小さなパッチでした。 distutils への彼の興味は、最終的に Windows インストーラをポイント・アンド・クリックで作成する bdist_wininst コマンドを作成することにつながりました。そこから Greg Ward は彼を python-dev グループに招待し、最終的に彼はコミット権を得ました。

py2exe

多くの Windows ユーザーと同様に、彼も1つの実行ファイルとして包まれた Python アプリケーションをデプロイする必要性がありました。この問題に対する初期のアプローチは、Python の著名人である Fredrik Lundh の squeeze と Christian Tismer の sqfreeze を参考にしました。そして、Thomas は Gordon McMillan の Installer プロジェクトへ複数のパッチを投稿しました。

彼は distutils に興味があったので、パッケージングライブラリの拡張機能に Installer が移植できないかを検討しました。しかし、結局は既存の distutils フレームワークを活用するためにそのソースを書き直すことになりました。最終的に、彼はそのプロジェクトを py2exe というシンプルで分かりやすい名前にしました。

ctypes

ctypes のアイディアは、当時 pywin32 が提供していたものを超える要求から出てきたものです。さらに彼の Scheme での作業は Windows API へのインタフェースを必要とし、それは彼の Python での作業においても全く同じものでした。そのため、彼は自分のプロジェクトをやり続けたかった。

ctypes は、Thomas がそのプロジェクトを公開してほしいという数え切れない要望を受け取ったことから、2003年の Python 2.3 リリースにあわせて最初のリリースを公開しました。彼の Starship ページには小さな個人プロジェクトに使われているライブラリのように説明されていますが、このライブラリは、たちまちに広く使われるようになりました。

彼はもともと Windows 上でこのプロジェクトを開始しましたが、すぐに Linux 移植の要望を聞くようになり、コミュニティが彼を支援する形になりました。Linux 移植は libffi を導入しました。彼もまた Windows 上での低レベル実装を置き換えるために libffi を使い始めました。

2006年に Python 2.5 の標準ライブラリとして受け入れられた ctypes 1.0 がリリースされました。彼の数年間に及ぶ開発と年間何度もリリースを行う活動の結果、Python と共に提供される ctypes はデフォルトとして広くユーザに使われています。

今日の ctypes が在るのは、多くの人が関わってくれた結果です。Thomas は関わってくれた全ての人に感謝していて、特に Robin Becker へお礼を述べます。Robin は、プロジェクトの初期段階で尽力され、知識と励ましの双方を提供してくれました。

ctypes の新たなメンテナ募集

Thomas が長年かけてがんばってくれた後に、このプロジェクトが停滞するのを我々は見たくありません。あなたが C 言語の経験をもち Python プロジェクトを支援する時間があるなら、コミュニティはあなたの貢献に深く感謝します。新しい開発者ガイドを調べた上で詳細はバグトラッカーを検索してください。

更新: リンクを修正しました。

チーム紹介: Benjamin Peterson

2011-04-28T08:00:00.000+09:00

原文はこちら: Meet the Team: Benjamin Peterson

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

名前:	Benjamin Peterson
所在地:	アメリカのミネソタ州
ホームページ:	http://benjamin-peterson.org
ブログ:	http://pybites.blogspot.com

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

3.5年です。

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

この3月25日でちょうど3年です。

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

私の最初の提案は、個人的に Guido 自身によって却下されました。運が良いことに、私は強く主張して、いくつかのパッチが受け入れられました。最初のコミットは Misc/ACKS ファイルの順番を並び替えたものだと思います。

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

パーサ、コンパイラ、インタプリタのコアが好きですが、Python のコア開発の全ての分野に手を出していると知られています。但し Windows 以外ね！

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

Python で Python インタープリタ (http://pypy.org) を実装しています！このように、私は心の底から Python 実装者なんです。:) Python 2 と 3 の互換ライブラリである six (http://pypi.python.org/pypi/six) の開発者でもあります。

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

音楽を創ったり、クラリネットを吹いたり、数学の本を読みます。時々ちょっとしたハイキングにも出かけます。

Python 2.7 と 3.x における段階的な廃止プロセス

2011-04-27T12:17:00.002+09:00

原文はこちら: Deprecations between Python 2.7 and 3.x

最近の python-dev の議論で、Python 2.7 から Python 3.x の最新バージョンへ移行するときに遭遇する、いまの Python の段階的な廃止プロセスのポリシーに関する問題が浮き彫りになりました。この問題の結果として、Python ユーザが古いバージョンを調べずに Python 2.7 から 3.x の最新バージョンへ普通に移行するという事実を考慮して、開発チームはいまの段階的な廃止プロセスのポリシーを変更しました。

背景

Python は後方互換性に対して強いコミットメントをもっています。互換性のガイドラインに準拠しない限りどんな変更も認められません。それは正しいプログラムが Python の新しいバージョンで実行できるというのが本質的なところです。しかし、このことは必ずしも可能だとは限りません。例えば、API が明確に分割されていて、他のものに置き換えられる必要がある場合です。そういった状況では、Python は段階的な廃止プロセスのポリシーに従い、1年間の移行期間を設けた上で、その削除される機能を公式に廃止します。移行期間中は、開発者が自分たちのコードを修正できるように廃止予定であることを表す警告を提示しなければなりません。Python の段階的な廃止プロセスのポリシーの詳細は PEP 5 に記載されています。その変更は新しい Python のリリースのみに行われるので、通常はリリース間で18ヶ月間の猶予があります。これは1つのリリースが標準の廃止期間であることを意味します。

このポリシーに対する例外の1つが Python 3 でした。Python 2 から Python 3 へのメジャーバージョンの変更は、特別に後方互換性を壊してでも、Python の開発者が既存ポリシーの範囲内ではシンプルに修正できない課題を是正する機会であることを目的としていました。例えば、デフォルトの文字列を Unicode にすることやリストの代わりにイテレータを返すことです。

並行開発

多くの推計では、Python 3 への移行期間は5年かかると言われています。Python 2 と 3 の並行開発が行われることがありました。

Python 2.7 は Python 2 の最終リリースになります。そのメンテナンス期間は、かなり期間延長されることが合意されています。最終的には、Python の新バージョンへ移行したい開発者は Python 3 へ大きな変化を遂げる必要があります。

ここに1つ問題があります...

廃止機能にびっくり

python-dev のスレッドで、ある特別な C API の関数 PyCObject_AsVoidPtr に注目が集まり、その関数は適切な警告もなく削除されました。さらにこれは遵守すべき段階的な廃止プロセスのポリシーを破るものでした。一体何が起こったのか？

この変更は、古い API (PyCObject) から新たに改善された (PyCapsule) への大きな移行の一部でした。この問題は PyCObject がデフォルトで、実際には Python 2.6 でのみ、その API が利用可能です。そして、Python 2.7 で廃止されました。Python 3.2 では、その API は存在せず新しい PyCapsule が使用されます。Python 2.7 リリース (2010年7月) から Python 3.2 リリース (2011年2月) への廃止期間は約7ヶ月間でした。この廃止期間は最低12ヶ月間よりもかなり短く、開発者が Python リリースの妥当な期間をサポートするのが難しくなります。

3.0 から 3.1 、そして 3.2 へ移行する廃止期間は大丈夫です。廃止期間をもつ Python 3.1 は2010年3月にリリースされて、3.x リリースの途中であり、ほぼ12ヶ月間の廃止期間が有効でした。しかし、実際には開発者にとってその廃止期間が有効ではありませんでした。開発者は Python 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 API のラッパーとして実装されていました。Python 3.1 の実装がサードパーティ製品の用途に展開できると、それを必要とする者から提案がありました。さらに、開発者の移行を支援するドキュメントとその変更の背景にある理由を記述するために、変更に関する "遡及効果のある" PEP に記載する内容だと合意されました。

もう1つ一般的な注釈として、Python の開発チームは、いまこの問題に気付いて再発しないように取り組んでいます。Guido はその状況のレビューを投稿しました。そして、Python 3 は当分の間、段階的な廃止プロセスを保守的なものにすべきだと提案しました。最低限、廃止予定の API は、開発者が Python 2.7 から移行できるように、実際に削除される前段階で長めに保持されます。

さらに間接的には、このスレッドで幅広いユーザに対して Python の変更を効果的且つタイムリーに伝える方法について課題が残りました。まさにこのブログが正面から取り組んでいる課題です。

つまりは、どういうこと？

まず第一に Python の開発者が全てにおいて、いつも正しいというわけではありません。開発者の生活に困難をもたらすという意味ではなく、単に開発期間中に発見されないものもあるということです。

次にその問題を修正することは、良いことよりも悪影響をもたらすので PyCObject の API は復活させません。復活させることで、その変更に関連する開発者を助ける可能性はありますが、全体として互換性の問題をより複雑にしてしまいます。その一方でこの問題に耐えて進歩しなければなりません。今回は教訓が得られたので、次に同じ間違いをすることはありません。

この問題が示したことは、Python の開発者はユーザからの意見を聞きたいということです。互換性はとても重要です。そして、新しいバージョンになるべく問題を発生させずに移行できるようにあらゆる努力が行われています。特に標準ライブラリの開発者は、妥当なレベルの努力で複数の Python バージョンをサポートすべきです。

最後に Python の開発者は 2.7 を放棄していません。新しい機能が取り込まれず、2.8 もリリースされませんが、それでも 2.7 を使用するユーザの視点を大事にしています。2.7 を使用するユーザの準備が整ったときに 3.x への移行を保証することは、Python コミュニティ全体にとって極めて重要なことです。

ポーリングについて futures と並列実行

2011-04-26T09:50:00.000+09:00

原文はこちら: Of polling, futures and parallel execution

いまのコンピューティングの大きな関心ごとの1つは省電力です。多くの携帯デバイス (ラップトップ、タブレット、ネットブック) にとって大きな課題です。最新の CPU はアイドル状態のときに段階的に低消費電力状態に入ります。アイドル状態が長くなると、より深い低消費電力状態になりバッテリーの消費量も少なくなります。そのため、たった1回の充電でデバイスのバッテリーライフが長くなります。

低消費電力状態にはポーリングという敵がいます。あるタスクが定期的に CPU を利用するとき、潜在的変化を調べるためにメモリの位置を読み込むような些細な処理であっても、CPU は低消費電力状態から復帰してきて、その内部構造を全てを利用します。単調で定期的な実行状態はその目的の処理を完了してから随分経った後で再び低消費電力状態へ入ります。インテル社は、ポーリングという動作そのものを電力を浪費する懸念事項と考えています。

Python 3.2 は、並列タスクを起動する concurrent.futures モジュールという新たな標準ライブラリを提供します。そのライブラリは並列タスクが終わるのを待ちます。そのコードを詳しく調べてみると、ワーカースレッドやプロセスの一部にポーリングが使用されていることに気付きました。"一部" というのは、 ThreadPoolExecutor と ProcessPoolExecutor の実装が違っているからです。前者はそれぞれのワーカースレッドがポーリングを行います。一方、後者はワーカープロセスと通信するために使用される1つのキュー管理スレッドのみがポーリングを行います。

ここでは、ポーリングはシャットダウンの手続きが開始されるときを検出するというたった1つの処理のみに使用されていました。呼び出し可能オブジェクトをキューイングする、もしくはキューに追加されたその直前の呼び出し可能オブジェクトからの結果を取得するといったその他のタスクは、同期キューオブジェクトを使用します。これらのキューオブジェクトは、使用している Executor の実装に依存した threading か multiprocessing モジュールのどちらかにあります。

そのため、私はシンプルな解決方法を思い付きました。私はこのポーリングを None という組み込みのセンチネルに置き換えます。キューが None を受信すると、待ち状態のあるワーカーは自然に起動してシャットダウンすべきかどうかを確認します。ProcessPoolExecutor では、1つのキューマネジメントスレッドに加えて、N 個のワーカープロセスを起動させる必要があるといった、ちょっと厄介な問題があります。

私の最初のパッチでは、それでもポーリングのタイムアウトを持たせていました。ある時点でワーカーが起動するかなり長いタイムアウトです (10分間) 。コードがバグっているときに発生する長いタイムアウトですが、必要なときに前述したセンチネルを通してシャットダウンの通知を取得できませんでした。好奇心から、私は multiprocessing のソースコードを読み始めて、また別の興味深い見解が得られました。Windows 環境では、ゼロ以外の有限なタイムアウトをもつ multiprocessing.Queue.get() がポーリングを使用します (私は課題 11668 を登録しました) 。それは 1 ミリ秒のタイムアウトから始まり、ループする毎に増加する高頻度のポーリングを使用します。

それでもタイムアウトを使用していると言うのは確かにそうですが、そのタイムアウトが長く、Windows 環境で私のパッチは役に立ちません。それは 1 ミリ秒毎に起動して実行するように実装されているからです。私の最新のパッチは全くタイムアウトを使用しないので、プラットフォームに関係なく定期的に起動することはありません。

歴史的に説明すると、Python 3.2 以前では、 threading モジュールの全てのタイムアウト機能や、 multiprocessing それ自身が様々なタスクのためにワーカースレッドを使用するので multiprocessing においてもそのほとんどがポーリングを使用します。これは課題 7316 で修正されました。

2011 言語サミットレポート

2011-04-25T16:44:00.003+09:00

原文はこちら: 2011 Language Summit Report

今年の言語サミットは、PyCon が始まる前日の3月10日(木)にアトランタで開催されました。出席者は、 CPython, PyPy, Jython, IronPython, Parrot VM のメンバー、 Fedora, Ubuntu, Debian のパッケージャ、 Twisted プロジェクトの開発者やその他のプロジェクトのメンバーが集いました。

開発ブログ

最優先課題の1つは、PSF の広報ディレクターを務める Doug Hellmann がまさにこのブログの議論を始めました。python-dev メーリングリストの流量の多さ、且つ頻繁に議論が活発になりがちなために、ユーザにとって開発のニュースを知るお手軽な方法としてブログが望まれました。このブログでは、PEP、大きな意思決定、新機能、致命的なバグ修正、そして開発プロセスの中で何が起こっているのかの親しみやすい話題も提供していこうと計画しています。

全ての Python の実装はこのブログに投稿できます。例えば、PyPy は既に自らのプロジェクトで活発なブログをもっていますが、彼らは同じようにこのブログにもそのニュースを投稿することに協力的です。関連した議論は python.org ダウンロードページでも紹介されている代替の実装につながります。そういったリリースもまた python.org のトップページでニュースとして掲載されます。

互換性の警告

Python 3.2 で CPython の参照カウントに依存したコード領域をユーザが検出できるように ResourceWarning を導入しました。この警告はユーザがもっと優れたコードを書くのに役立つだけでなく、安全なクロス VM コードを書けます。さらにクロス VM な互換性のために CompatibilityWarning という新たな警告の型が提案されました。

このアイディアは、最近登録された PyPy の開発者が発見した CPython のバグがきっかけでした。課題 #11455 は、CPython では、ユーザが __dict__ に非文字列のキーをもつ型を生成できるということを説明します。それは少なくとも PyPy や Jython ではサポートされていません。理想としては、まさに ResourceWarning と同様に、ユーザがそういったケースを検出するために警告を有効にできるようにします。

標準ライブラリの独立化

いま CPython のソースを Subversion から Mercurial へ移行することが完了しました。標準ライブラリを独立したリポジトリへ分割して外部へ出そうというアイディアが復活しました。代替の実装の開発者は、彼らの開発プロセスが大幅に簡略化できるのでこの方針転換に高い関心をもっています。これまでは CPython のスナップショットを取り、C 拡張をピュア Python のバージョンなどに置き換える特殊なパッチを任意の実装に適用しています。

この方針転換は今後 PEP として提案される必要があります。そして、議論の争点の1つとしてバージョン管理をどう行うかが話し合われます。標準ライブラリは任意の実装の外部にあるので、そのライブラリ自身がバージョンをもつようになります。さらにテストも同様にバージョンを考慮する必要があります。

標準ライブラリを外部へ出すことの別の話題は、ピュア Python 実装とそれに対応する C 拡張に関するものでした。PyPy プロジェクトの Maciej Fijalkowski が時間をかけて話しました。モジュールによっては、ピュア Python と C 拡張で少し機能の違いがあります。外部へ出すことの議論が進むにつれて、PyPy プロジェクトのグループは、その利用がどこへも不利益をもたらさないように、そういったモジュールを変更するためにより厳密な方法を提案しました。さらに、C 拡張はパフォーマンスの向上が図れるときのみに作成し、ピュア Python 実装が C 拡張よりも優先されることが決定されました。

パフォーマンスベンチマークサイト

PyPy スピードセンターは、PyPy のパフォーマンス結果を提示するという偉大な功績を収めました。python.org と同じような performance.python.org をどうにかホスティングして、全ての VM を参加させることについて議論しました。パフォーマンスのベンチマークに加えて、その他にもメモリ使用量、テスト結果、言語の互換性なども考慮されます。これまで PyPy 対 CPython の検証を行っていたように、複数の Python 実装と連携するインフラを適合させるように取り組む必要があります。

Allison Randal が役員を務めるオレゴン州立大学のオープンソース研究所に高パフォーマンスのマシンを設置するお話が、新たなスピードセンターが活躍するための場として議論されました。Jesse Noller は、その研究所に設置するハードウェアを手に入れるために尽力することに言及しました。寄付は歓迎しています！

あなたが、またはあなたの組織がこの話題に関連して寄付に興味をもっているなら、 Python ソフトウェア財団へ連絡して、寄付のページで支払ってください。

モラトリアムの解除

CPython 3.3 の開発が開始されると同時に言語の変更に対してのモラトリアムが解除されます。水門は開かれていますが、代替の実装が追いつけるように変化の速度を遅くしている上に、言語の変更は保守的なものになると予想されます。モラトリアムの結果、どの代替の実装も 3.x に追いつけなかったけれど、PyPy と IronPython は最近 2.7 との互換性を保持して、IronPython は 3.x の開発が始まっています。

3.3 に期待されている言語の変更として、承認済みの PEP 380 が楽しみです。この PEP は、あるジェネレータが別のジェネレータへ yield できるようにする yield from <expr> という構文を導入します。これ以外には、特に言語の変更の見通しはありません。

例外属性

その次の話題は、ユーザへ文字列のメッセージを強制させるよりも、もっと良い属性を提供する例外についての迅速な議論がありました。例えば、ImportError は、インポートに失敗したことを調べて解析するよりも、そこへ簡単にアクセスする方が便利です。

この実装は、例外オブジェクトの初期化時にキーワード引数のみを受け取ります。いまでも ImportError ケースのためにパッチが存在します。

貢献者の同意

貢献者の同意についても議論されました。いくつかの電子契約フォームが水面下で進められています。Google の個別貢献者の同意は、新たなシステムがうまく機能するようにそういった発想のために参考になるものの1つです。この話題は長期間、議論されてきました。たくさんの人がこの分野の解決策を待っています。さらに、アメリカ以外の地域でも有効な電子契約への移行を保証するために研究が行われています。

Google サマーオブコード

Martin von Löwis は、PSF の傘下にある Google サマーオブコードを紹介する会議を設けました。メンターとしての役割を行わない開発者も望まれます。つまり、研究する学生のためのプロジェクトを提案することです。プロジェクトを提案することが、メンターになることをほのめかすものではないことを覚えておいてください。何らかの方法で協力したいなら、PSF のプロジェクトとメンターの公募を参照してください。

Distutils

Distutils2 が取り上げられました。Tarek Ziadé は、彼らのスプリントのゴールは Python 3 への移植を完了して、Python の標準ライブラリへの最終的なマージの準備をしていると話しました。さらにマージと共に新たな名前 packaging となります。packaging チームは、Python 2.4 から 3.2 までをサポートする Distutils2 という名前で独立したパッケージを提供することも計画しています。

PyCon スプリントの大きなグループの1つだった packaging スプリントは、大成功でした。彼らの現在の成果は標準ライブラリのマージを待っている Bitbucket にあります。

代替の VM の未来

IronPython は、将来の計画と 3.x リリースを次に控えていることについて話しました。開発プロジェクトが Microsoft から引き継がれ、彼らは PyCon の場で初めてのコミュニティベースのリリースとなる 2.7.0 リリースをアナウンスし、数ヶ月以内に 3.x を対象に開発を始めます。

Jython は最近 2.5.2 がリリースされて 2.6 リリースの計画が始まりました。2.6 と 2.7 の違いはそう大きくないので 2.7 へジャンプすることを提案する人もいましたが、もしジャンプするなら最初のリリースは時間を要するかもしれません。"リリースは早めに、リリースは頻繁に" は、その話し合いの中で出た引用の1つです。彼らは任意の 2.6 から 2.7 の違いを調べた後で 2.6 から 3.x へ進める可能性があります。

開発資金

3.x 開発計画の中で開発資金を使って代替の実装が 3.x へ追いつくのをスピードアップできる可能性があるかという話題がありました。資金を投入することはできるけれども、PSF への提案は、全てが議論される前に作成する必要があります。そういった取り組みの助成金を受けるのに興味がある人たちは PSF の役員会へ連絡してください。

ベースライン Python

Jim Fulton は、彼が "ベースライン" Python と呼ぶものについて議論を始めました。彼が Python アプリケーションをデプロイしてきた経験では、システムの Python は予測不可能で対象とするのが難しいと分かりました。Fedora と Ubuntu/Debian のパッケージングの専門家と一緒に、なぜシステムの Python がそのようにデプロイされるかの理由を知ることができました。

Fedora では、基本となる Python のインストールは Live CD を考慮しています。そのため、少しの依存関係をもつとても小さなインストールで、基本的には最低限の実行環境です。その他の違いは、ディレクトリの配置、distutils のような標準的なライブラリモジュールの除去、またはディストリビューションが提供する廃止されたライブラリです。

すぐに明確な解決策は出ませんでしたが、この関係者はその問題に継続して取り組んでいます。

3.3 の機能

2つの PEP を含めた 3.3 の機能の話題がありました。名前空間パッケージを扱う PEP 382 はそのサイクルのある地点で現れます。さらに distutils のマージの話題の中でも話されました。

柔軟な文字列表現を定義する PEP 393 も議論され、Google サマーオブコードのプロジェクトとして学生の興味をひいていました。その実装に加えて、それらが受け入れられるかを把握するために新たな内部のメモリ特性とパフォーマンスに取り組む必要があります。

Unladen Swallow

Unladen Swallow は、現在 "休息" 状態にあり、CPython 3.3 にそのままは含められません。その分野の専門家がその作業を行えなくなり、さらに発展させるには複数の優秀な専門家を特定する必要があります。議論の中では、開発資金を使って Unladen Swallow を次の段階へ進められるものかどうかが再度、議論されました。この内容に興味があるチームは PSF へ問い合わせてください。

Unladen Swallow は、休息状態であり、今後はどうなるか分かりませんが、このプロジェクトは Python とオープンソースコミュニティ全般に対して大きな貢献を行いました。Unladen Swallow で使用されるベンチマークツールは、例えば、代替の実装をテストするのにかなり便利です。さらに、Unladen Swallow の開発者から LLVM や Clang への貢献は、同様にそういったプロジェクトを助けるものでした。

その他に2つのパフォーマンスのアイデアも Dave Malcolm のインライン関数の提案を含め、手短かに議論されました。Martin von Löwis は彼が開発中の JIT 拡張モジュールを話しましたが、PyPy 開発者はこの種の JIT の有効性に懐疑的な見解を示しました。

非同期フレームワークの道を敷き詰める

その日の最後の議論は、標準ライブラリへ Twisted のライブラリを統合するものでした。主なアイデアは、Twisted やその他の非同期プログラミングフレームワークへ簡単に移行できる asyncore を代替するものでした。

このプロセスは PEP として提案されていて、非同期のイベントループがなかったら、WSGI リファレンスと同じような目的を提供する方法がいくつか提案されています。PEP の著者に加え、Twisted プロジェクトやその他の開発者は、みんなが同意するように取り組む必要があります。

その他の情報

詳細な情報については、CPython 開発者である Nick Coghlan の rough notes や highlights を参照してください。

Python Insider JA

2012 言語サミットレポート

名前空間の PEP

importlib の状況

リリーススケジュール PEP

Python ソフトウェア財団からの資金

virtualenv の追加

PEP 397 の追加

speed.python.org

PEP 411 の追加

全ての組み込み関数でのキーワード引数

Python 3 への移行

ハッシュの疑似乱数

新しい dict 実装

新しい pickle プロトコル

チーム紹介: Brett Cannon

チーム紹介: Michael Foord

Windows 向け Python ランチャー

ランチャーについての詳細

シンプルな使い方

参考文献

CPython 3.2.1 リリース

3.2.1 RC2 リリース

修正箇所

I/O

Windows

subprocess

その他

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

2.6.7

2.7.2

3.1.4

3.2.1

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

貢献者の募集

早期の成功

行動規範

参加表明

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

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

致命的なエラー

タイムアウト

ユーザシグナル

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

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

早期の成功

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

Jython リポジトリを Mercurial へ移行

Python 3.3 から OS/2, Windows 2000, VMS のサポート終了へ

PEP 11

あなたができること

メンテナになる

ビルドスレーブに貢献する

Python Insider 翻訳プロジェクト

協力者、募集

チーム紹介: Brian Curtin

チーム紹介: Nick Coghlan

新しいブログデザイン

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

問題を報告する

レポートに対応する

問題を修正する

チーム紹介: Tarek Ziadé

AST (抽象構文木) の変更管理ポリシーの策定

AST の互換性

他の Python の実装

この後どうなるの？

Thomas Heller が ctypes メンテナを辞任

Python

py2exe

ctypes

ctypes の新たなメンテナ募集

チーム紹介: Benjamin Peterson

Python 2.7 と 3.x における段階的な廃止プロセス

背景

並行開発

廃止機能にびっくり

さて、どうしよう？

つまりは、どういうこと？

ポーリングについて futures と並列実行

`importlib` の状況

`virtualenv` の追加

新しい `dict` 実装

新しい `pickle` プロトコル