最近のPython-dev(2018-06)
バックナンバー:
Python 3.7
日本時間の6/28に Python 3.7 がリリースされました。 終盤に駆け込みで2つ大き目の変更が入りました。
- Unicode 11 対応
- ASTの変更の revert
Unicode 11 はデータの更新だけなので危険が少ないし、1.5年後の3.8まちにはしたくないということでGoサインが出ました。
AST は、僕が中心で行ったAST段階での定数畳み込みの準備として、 docstring とそうでない文字列の区別をAST段階でつきやすくために変更していました。
その変更によりいくつかのライブラリで問題が報告されていたのですが、AST はもともと後方互換性を保証していないからとライブラリ側での対処がされていました。しかし、RCフェーズに入ってから IPython が他と異なる壊れ方をしていて、今のASTに関するAPIが IPython のニーズを満たしておらず想定外の対処が必要になっていたことから、一旦元に戻してまたAPIから考え直そうということになりました。
もちろんこのASTの変更を元に定数畳み込みが作られていたので、定数畳み込み後に docstring と文字列定数の区別がつかなくならないように Python 側にハックが必要になるのですが、僕が週末作業できないあいだに Serhiy がやってくれました。 https://github.com/python/cpython/pull/7121/files/8ee9227599583c460ff8faf9c1ab1670559a1224#r191080934
Compact GC Header
Python 3.8 に向けた大きめの改善の1つめに、2000年以来変更されてない循環参照GC用のメモリオーバーヘッドの削減に挑戦しています。
ちょうど 6/25 に、低レベルプログラミングが話題になることが多い Turing Complete FM のリスナーが集まる ミートアップイベンント があったので、そこで発表してきました。
基本的にはつぎのような戦略で、GC用ヘッダのメモリ使用量をポインタ3つ分から2つ分に削減しています。
- 双方向リンクリストの逆方向リンクを、一時的に潰してGC用の参照カウントに使い、必要になる前に戻す。
- ポインタの下位3bitを他の用途に使う (tagged pointer)。参照カウントに使うときは左に3ビットシフトする。
一旦動くようになったものの、問題がありました。
- 参照カウントを3ビットシフトしたら、ポインタサイズが4バイトの32bitアーキテクチャでオーバーフローする危険がある。
- マイナーなアーキテクチャ上のマイナーな malloc 実装が8バイトアラインしなかった場合、ポインタの下位3bitを使うのも危険。
その後、2種類の実装のメンテナンスはなるべく避けたいので、必要な期間が一番短かったビットを逆方向リンクのポインタではなく順方向リンクのポインタの下位ビットに押し込めるという改良を行いました。現在レビュー待ちです。
FASTCALL を PyFunction, PyCFunction 以外でも利用できるように
Python 3.6 から段階的に、インタプリタ内部で関数の引数の受け渡し方を変更する FASTCALL 方式が導入されています。
これを利用するために、現在は Python で実装された(バイトコードをインタプリタが実装する)関数を表すクラスと、C言語で実装された関数/メソッドを表すクラスが特別扱いされています。
さて、 Cython はもちろんC/C++言語で関数を実装するのですが、トレースバックなどでソースコードを表示できるようにしたいなど、Python組み込みのC言語で実装されたクラスでは足りない機能を追加するためには独自の型を使う必要があり、そうすると FASTCALL が利用できません。
それを改善するためにいくつかの提案がされていて、最新のものが PEP 580 になります。
提案者の議論の仕方がちょーっと強引すぎて摩擦を感じてはいるのですが、技術的にはまぁ正しい方向だと思うし、ちゃんと動く参照実装も素早く作ってくれているので、個人的には前向きに捉えています。
とはいえ、そもそも FASTCALL ってまだ破壊的変更が入るかもしれない内部専用APIを Cython が先走って採用しているだけで、どう考えても PEP 580 は先走りすぎなんですよね。
まだ 3.8 の開発は始まったばかりなので、 FASTCALL を stable & public 扱いにできないかの議論を始めたりしてフォローに回っています。
PEP 572 (代入演算子)
PEP 572 の議論は大炎上しました。5月にLanguage Summit があってそこで議論のオーバーヒートをどう扱うかなどの話がされたのですが、 LWN.net がその まとめ を作ってくれたところから、またML上での議論が再開し長大なスレッドになっています。。。
@methane