最近の Python-dev (2017-03)
バックナンバー:
Python 3.6.1rc1
Python 3.6.1rc1 がリリースされました。大きな問題がなければ 3.6.1 は 3/20 にリリースされる予定です。
3.6.1 は Github に移行してから初めてのリリースになります。なにか問題がないか確認するために、いつものRC版以上にソース形式・バイナリ形式両方の配布物のテストが必要なので、可能な方は協力をお願いします。
Github 移行後日談
以降から1ヶ月が経ちました。開発者からのフィードバックはおおむね好評です。私は、気軽にプルリクエストをくれた人がCLAにサインしないまま放置して大量のマージできないプルリクエストが貯まることを懸念していたのですが、今までののところそれも大丈夫そうです。
一方で Misc/NEWS といういわゆる changelog にあたるファイルが頻繁にコンフリクトを起こしていて解決する新ツールが開発中だったり、プルリクエストをマージするときのコミットログのフォーマットなどが話し合いでルール決まったけどまだドキュメント化されてなくて Github のデフォルトのままマージされるケースが多いとか、細かい問題はまだまだ続いています。
また、Travis-CI でのテストをパスすることをマージボタンを押すのに必須の設定にしているのですが、それがよく遅延する問題がありました。簡単な修正のバックポートでいちいち待ってられない。既に Travis-CI に (幾つかの Python 関連 organization 共有で) 並列25jobを割り当ててもらっていてこれ以上は望めない。どれかテストを削ろう。という話し合いをしていたら、「あ、並列25jobの件、今日アクティベートされたから。」という書き込みがあり、実際その日以降 Travis-CI のテストは快適になりました。まだアクティベートされてなかったなんて誰も知らなかったよ…とはいえ Travis-CI さんには100万の感謝を。
CPython 3.7 is now faster than CPython 2.7 on most benchmarks
いろんなアプリを集めたベンチマークで Python 2.7 と 3.5 を比べた時は速くなってるのと遅くなってるのが半々くらいだったのですが、 Python 3.6 やそれ以降の高速化によってそろそろ Python 3 の方が速いと胸を張って言える感じになってきました。具体的には10%以上遅くなったベンチが12件に対して、10%以上速くなったベンチが23件あります。
ちなみに遅くなってるベンチのトップ2は Python コマンドの起動 (`-S` オプションありなしの2種類) です。例えば Python 2 では組み込みの open
関数は C 言語の FILE*
をラップしたオブジェクトを返していて、完全に Python インタプリタ内で実装されていたのですが、 Python 3 では FILE*
が使われなくなり代わりに io
モジュールが利用されるようになったため、起動時に io
モジュールとその依存モジュールがインポートされるようになっているのが遅くなってる原因の1つです。
起動が遅くなったと言っても数ミリ秒ですし、起動時にインポートされるモジュールは利用頻度が高いモジュールなので、 Python 本体の起動は遅くなっていても Python で書かれたアプリの起動時間には(結局アプリがそのモジュールをインポートする可能性が高いために)影響しないことが多いはずです。
とはいえ起動は1ミリ秒でも早いに越したことは無いですし、中二病な vim プラグインで有名な方が Python の起動が (特に Lua と比べて) 遅いと愚痴をこぼしているのを Twitter で見る機会もよくあったので、 メンテナンスコストとのバランスが取れた範囲での最適化 をしているところです。
PEP 543 -- A Unified TLS API for Python
Python には昔から ssl という標準ライブラリがあるのですが、これは OpenSSL を Python から使うためのものです。
最近は一層TLSの重要性が増しているのですが、 Windows などで OpenSSL をバンドルして配布してる環境で OpenSSL のセキュリティーアップデートを配布する必要が出てきてしまいます。 macOS でも、 Apple がシステムの OpenSSL を deprecate してしまってもうちゃんとメンテしてくれてないので、 Windows と同じ問題が発生しています。 (PyPI が CDN に fastly を使っている関係で、 macOS のシステムの OpenSSL が対応してない TLS v1.3 が必須になるという一大イベントも最近ありました。)
OpenSSL をやめて macOS では SecureTransport, Windows では SChannel を使えば、 OpenSSL に依存せずに、 Apple や Microsoft がメンテナンスしてくれている証明書ストアとTLS実装を使うことができます。また最近は OpenSSL 以外の実用的なTLS 実装も増えてきています。 OpenSSL に依存せずに簡単に TLS を使えるような仕組みがあると多くの人が幸せになれます。
今回提案された PEP 543 は、そのはじめの一歩として、TLSのライブラリが実装するべき標準のAPIを定義して、 ssl モジュールにその API を実装させるというものです。これができれば、同じAPIに準拠した SChannel をラップするなどの別実装モジュールを PyPI で配布し、TLSを利用するライブラリは ssl とサードパーティライブラリの間でスイッチしやすくなるはずです。
提案はされたものの、実際に実装・利用することなくこれをレビューして議論できる人がいないので、試験的に実装して問題点がないか洗い出す方向で進んでいるはずです。
多分これが Python 3.7 で一番重要な新機能になるんじゃないかな。
Translated Python documentation
Python のドキュメントの翻訳が一番進んでいるのが、僕も参加している日本語訳(古い Python の changelog とか拡張を書く人しか必要としない Python/C APIのドキュメントも全部含めて85%以上!)で、次に翻訳が進んでいるのがフランス語(翻訳率は10%台だけどチュートリアルはカバーされている)です。
そんなフランス語の翻訳をされている Julien Palard さんが、 docs.python.org/<lang>/
配下で翻訳ドキュメントを公開できるようにしたいと 去年 python-ideas MLで提案していて、僕も翻訳の管理、自動ビルド、ホスティングなんかの下回りを共通化すれば他の言語でももっと翻訳がやりやすくなるだろうなと思って応援しています。
さて、 Python のドキュメントは Sphinx というツールで構築されており、翻訳も Sphinx が持つ機能を使っています。具体的には Sphinx が英文をパラグラフ毎に分けて gettext の POT 形式で出力したり、そのパラグラフに対応する翻訳文を mo 形式のファイルから読み込んで英文と差し替えることで、他の gettext を使ったOSSと同じような手順で翻訳ができるようになっています。
本家のドキュメントはもちろんこの機能を使わずに構築されているのですが、この機能を使うと問題が出る部分があり、日本語プロジェクトでは fork に修正を当てた状態で利用しています。幾つかの修正は日本語以外の言語の翻訳でも共通して必要なものです。ということで本家で修正するプルリクエストを作ったのですが、ドキュメント翻訳に否定的なメンバーから Reject されてしまいます。しかしその後 Victor Stinner さん(この1年ではダントツでトップのコミッター) が Accept してくれて、形式上2対1になりました。
一応マージボタンを押してもいい状況ではあるものの、別に急ぐ必要はないし様子見で放って置いたら、 Victor さんがさらに「翻訳を支援しようぜ」っていうメールを Python-Dev に投稿してくれ、多くの賛同のレスが得られました。 Victor さんマジイケメン。
そんなこんなで、問題のプルリクエストはマージしました。これからは Julien さん達と協力して、日仏以外の Python コミュニティの人も翻訳しやすい仕組みを作っていけたらなと思います。
ちなみに、現在 Python のドキュメント翻訳は Transifex というサイト (OSS向けの無料プランあり) で行っているのですが、今後のことを考えて Red Hat が作っている Zanata を試してみました。 Transifex が持っている重要な機能はほぼカバーしているし、 Transifex には無いバージョン機能(翻訳文のバージョン管理じゃなくて、同じプロジェクトの原文を複数バージョン持てる)があったり、サポートのレスポンスもすごく早くて良かったです。 また、 gettext 等の形式ではなく Web サイトを WYSIWYG で翻訳するなら、 Mozilla の Pontoon が良さそうでした。 何か OSS で翻訳プロジェクトを始めようとされている方は参考にしてください。
@methane