原文はこちら: 2012 Language Summit Report
今年の言語サミットは、 PyCon 2012 が開催される前にカリフォルニアのサンタクララで3月7日(水)に開催されました。前年と同様に、様々な Python VM やコミュニティプロジェクトの開発者、Linux ディストリビューションのパッケージャーが出席しました。
月曜日の PyCon スプリントで、その2つの PEP は却下されました (それぞれの PEP の上部に却下されたことが明記されています) 。Martin von Loewis は、その解決方法が見つかったと import-sig メーリングリストへ投稿しました 。そして Eric Smith がそのメーリングリスト上で合意された内容を新たな PEP として草稿を作成する予定です。事実上 PEP 382 は完全に却下されましたが、PEP 402 の一部分は承認されることでしょう。
既に存在する課題のみを要点にして議論が始まりました。その課題はディレクトリの 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 で詳細を整理して、レビュー内容を見直す予定です。
すぐに2つの PEP と結びつく標準ライブラリを分割して独自ライブラリにするアイディアが復活しました。しかし、テストスィートがどこに置かれるのかという疑問が残りました。さらに、標準ライブラリを取り扱うテストと、言語機能を取り扱うテスト間で区別する必要があるかもしれません。
3つのバージョンが必要になるというバージョン管理の話題が持ちあがりました。それらは言語仕様バージョン、その実装バージョン、標準ライブラリバージョンの3つが必要になると思われます。
多くのコメンテーターが、このような PEP はあまりに複雑過ぎると指摘しました。さらに、こういった変更のうちどれかに注意を払うユーザーが実際にいるのかという疑問もありました。我々のうち数人は「 私たち ならより素早いリリースのために使う」と明言しましたが、多くのユーザーは何らかの理由で古いバージョンか、他のものをずっと使うでしょう。つまり、誰がそのリリースを使うことになるか疑問に思いました。
Thomas Wouters は、類似の LTS スタイルのリリースを行う Python コンシューマーで Python "LTS" リリースのラインアップの難しさについて良い点を突きました。Ubuntu とその LTS スケジュールは主要な例です。Ubuntu のような何かのプラットフォーム上で動くリリースを計画する組織も同様です。出席していた多くの Linux ディストリビューションのパッケージャーが頷いているようでした。
広く合意を得られたことの1つに、標準ライブラリのリリースサイクルを短くすることは、新たな貢献者にとっては良いことだということです。新たな機能追加に興味をもつ開発者からみて、一年以上に渡ってリリースしないというのはおもしろくありません。バグ修正を行ったとしても、時にはそのリリース期間があまりに長くなってしまうかもしれません。そのリリース時期というのは、可能な場合にユーザーが自分たちのコード内で我々の問題を修正してしまうところです。
Guido は、"自分のパッケージが標準ライブラリに含められるほどには認められていない" という考えをもたないようにする方法についてコメントを続けました。その要点は、PyPI 上でホストされている1つのプロジェクトであり続けることです。現実の世界で成功を収め、そのプロジェクトと API 群が成熟してから標準ライブラリへの追加を慎重に議論します。
素早いバグ修正リリースはおそらくは良いことだと提案されました。しかし、そのパッケージの開発者たちが、より頻繁なリリースを行うために労力を惜しまず動いてくれるかを保証するため、我々はリリースマネージャーと共に確認する必要があります。その新たな機能リリースと同様、新たなバグ修正を行ったものを使うユーザーがいることも確認しなければなりません。
また、以前の "sumo" というリリースに関する議論も行われました。そういった類いのリリースは、既にサードパーティーベンダーが行っています。このアイディアは大きな推進力を得るようには思えませんでした。
Steve と Jesse Noller は、全ての Python 実装だけでなく、サードパーティーのプロジェクトに向けても支援することに強い意志をもっていました。あるプロジェクトが資金提供を受けるのに必要なことは、そこで成し遂げられるものへの具体的な提案です。彼らは資金提供の準備は整っているのに、それが待ち状態であることにストレスを感じていました。つまり提案することは、その待ち状態を解除する手段です。
資金提供のアイディアのいくつかは Steave からのものでしたが、会場内からも出ました。1つのアイディアとして、1ヶ月休職するのに資金提供するという議論がありました。そして、それは誰ができるかという問題がありました。何人かは、開発コミュニティにいるフリーランスのコンサルタントが雇いたい開発者になるかもしれないと提案しました。こういったフルタイムの雇用は、実際に長期休暇を取得するのが難しいという結論になるかもしれませんが、誰にでもその可能性はあります。
別のアイディアでは、フルタイムでバグトラッカーを見てその流れを良くする誰かに、理想的には既にそういった選定作業を行ってくれている人に資金提供する可能性について話しました。この種の資金提供の意図は、バグ修正は3日で完了したのに、そのパッチが取り込まれるのに3年かかるようなことを止めたいというものです。これは短期的に素晴らしいアイディアだと思う人がいましたが、その作業は大変な労力を伴い、それを行う個々人は燃え尽きてしまう可能性が考えられます。誰かやりたい人がいれば、財団へそのアイディアを提案することをお奨めします。
トラッカーのメンテナンスと類似の内容で、Twisted プロジェクトの Glyph Lefkowitz は、コーディング後のコードレビューの取り組みに資金提供するアイディアを出しました。これは regex/re の状況を前へ進める良いアイディアだと推す人もいました。 regex はとても巨大で、標準ライブラリへの追加の障害となっている唯一のことは 徹底的なレビューだと多くの人が感じています。 cdecimal モジュールもレビューの補助が必要な別プロジェクトだという指摘もありました。
コードレビューへの資金提供は、サードパーティプロジェクトの Python 3 への移行を推進するアイディアの1つでもあります。特に言えば Twsited プロジェクトで、その開発者たちは資金提供を受けるような労力があることを感じていました。
ここに至り コアメンター グループは、新たな貢献者を取り込むのに成功していることを述べました。このことへの賛辞は、そのメーリングリストで行われています。
このサミットとは違う場での議論により、追加でこのランチャーが Python 3.3 Windows インストーラーでインストールされることが合意されました。その一方で、ランチャーをインストールしない独立したインストーラーとしても使えます。さらに、実装についての制約があまりにも細かい多くの低レベルな詳細を削除するという作業が PEP に行われます。例えば py.ini ファイルの配置の説明がそうです。
このプロジェクトは、技術的な問題ではなく人の問題に悩まされています。それは資金提供が行われる別の場所があると考えられました。しかし、お金があったとしても、時間、ノウハウ、タスクを完全に掌握できる人物をこれから探す必要があります。理想的には、最初のタスクは PyPy と CPython 実装の実行と比較を行います。その後、たくさんのインフラをラインに乗せます。
最初の提案は、ドキュメントのノートだとうまくいかないということでした。ドキュメントはユーザーへ通知する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 の変更についてかなり保守的にならないといけないという暫定的なライブラリのユーザーへも注意が必要です。我々が最もやりたくないことは、優れたライブラリのユーザーを動く標的にして、そのライブラリを導入することです。
この変更を行うために、 PyArg_ParseTuple 関数はより多くの処理を行う必要があり、そうすると遅くなることが既に分かっています。もう1つの方法として PyArg_Parse を使うと遥かに速いです。そのタプルバージョンは、組み込み関数のどのような変更にも関係なく、そこから1つか2つの引数を受け取ります。
組み込み関数を Python のものに置き換えるときに潜在的に互換性を壊してしまう箇所があります。それは、位置引数のみを受け取るときに潜在的に名前が競合するところがあります。
それは任意のブラケットルールを避けて、大掛かりな変更を行うよりも理にかなっているところの変更を維持することで広く合意されました。また我々は、実際のキーワード引数名に一致するように doc string を維持しておき、それらを一致させておくのと同様にドキュメントに留意する必要があります。
OrderedDict がキーワード引数のためのコンテナとして提案されました。しかし、Guido と Gregory はその使用例について不確かな様子でした。我々は、普通のディクショナリか、または順序付きディクショナリを使うかどうか、場合によっては、これらを処理するデコレーターを使うというのも提案されました。Python レベルの関数として PyArg_ParseTuple のような何かを公開するというところまで進みました。
関数シグネチャオブジェクトに関する PEP 362 は、一般にデコレーターで使われ、ここで役立ちます。残っている作業はその PEP をもう一度見直して、誰かが定義することだけにみえます。
移行ドキュメントに現実の世界の移行例をもっと紹介することが提案されました。理想的には、こういったプロジェクトのチェンジセットの移行についてです。クックブックスタイルのアプローチを取っている我々の移行ドキュメントは、良いアイディアだと支持する人もいました。
また、この実装はソート順序の違いをもたらすというユーザーに見える違いだけでなく、最近のハッシュのランダム化作業はこのことを問題点としているということも述べました。
質問やコメントがあれば python-dev へ投稿してください。
この記事は Eric Snow と Senthil Kumaran が投稿してくれました。ありがとう
今年の言語サミットは、 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 が投稿してくれました。ありがとう
0 件のコメント:
コメントを投稿