原文はこちら:
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 プロジェクトやその他の開発者は、みんなが同意するように取り組む必要があります。
