最近のPython-dev(2017-08)
バックナンバー:
https://docs.python.org/ja/3/
docs.python.org に言語スイッチのドロップダウンリストが追加されました。docs.python.org は Fastly を使っているので、 docs.python.jp よりも高速に閲覧できると思います。
docs.python.jp にあるセクション単位での英語ドキュメントへのリンク機能などがまだなくて単純な翻訳でしか無いので、すぐには docs.python.jp を止めるつもりはありませんが、将来的には docs.python.jp は docs.python.org/ja/ にリダイレクトすることを考えています。
PEP 550: Execution Context
Flask などのフレームワークではスレッドローカルストレージを利用して「コンテキスト」を作り、現在のユーザーの情報とかリクエストIDとかをそこに格納する事があります。しかし asyncio などのコルーチンではこれが使えません。
そこで、もっと高度に抽象化された、コンテキスト変数を扱うための仕組みが提案されています。
Hide implementation details in the C API
サードパーティーの拡張モジュールが利用している Python/C API が、 Stable ABI 以外は公開/非公開、マクロ/C関数が混ざり合っていて、 Cython なんかは非公開APIも積極的に使って性能を稼いだりしています。
現状のデメリットとして、 Stable ABI は使いにくいので余り使われていないのに対して、 API は雑然としていて他の Python 実装が Python/C API 互換の API を提供するハードルが高くなってしまっていたり、意図せずに実装詳細に依存したサードパーティーのライブラリが増えて将来の性能向上のための内部の大幅な書き換えをする場合に互換性の問題が起こる確率が増えてしまっています。
そこで、 Stable ABI と #include <Python.h>
の間を埋める、整理された Python/C API を用意しようという提案がされています。
個人的には、これによって今までマクロだったAPIがC言語の関数になり、RustやGoなどC言語以外の言語から Python/C API を呼び出しやすくなることに期待しています。
PEP 539: A new C API for Thread-Local Storage in CPython
Python の TLS のための C API が pthread_key_t を(90年代から) int 型にキャストして使っているのですが、これは posix 準拠ではありません。メジャーな環境では問題になっていないのですが、 Cygwin や CloudABI で問題になっていたそうです。
しかし、ABIレベルの後方互換性の問題があり、簡単に変えることもできません。ということで新しいAPIが提案されていたのですが、最近 Yamamoto Masayuki (ma8ma)氏がこの PEP に最近取り組んでいてもうそろそろ解決しそうです。
Cレベルの話で Python からは見えないのですが、日本人の活躍情報でした。