2012年4月7日土曜日

2012 言語サミットレポート

原文はこちら: 2012 Language Summit Report

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

名前空間の PEP

サミットは Barry Warsaw の進行のもと、PEP 382402 の議論から始まりました。少し議論を行った後、その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 407413importlib の議論に続くものでした。名前空間 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 は、標準ライブラリに暫定的なパッケージを含めることを提案します。最近、論議された regexipaddr モジュールは、この 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 が投稿してくれました。ありがとう

2011年8月28日日曜日

チーム紹介: Brett Cannon

原文はこちら: 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 を見ないときは、たくさん読書をします。主に雑誌やウェブサイトですが、常に何冊かの本を読みかけ状態です。

2011年8月13日土曜日

チーム紹介: Michael Foord

原文はこちら: 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 プログラマーはあまりいませんが、あらゆる類いの優れたギークたちが集まります。普通は、ただパブに集まって気軽に話したり、自分たちの最新のガジェットを披露します。

2011年7月12日火曜日

Windows 向け Python ランチャー

原文はこちら: 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 メーリングリストのスレッドで重要な議論が行われています。

CPython 3.2.1 リリース

原文はこちら: CPython 3.2.1 Released

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

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

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

2011年7月7日木曜日

3.2.1 RC2 リリース

原文はこちら: 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 をリリースできることに感謝しています。

2011年6月15日水曜日

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.statos.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 へ登録するようにしてください。