最近のPython-dev (2017-05)
バックナンバー:
PEP 545 -- Python Documentation Translations
3月号で紹介した、 Python 公式サイトで翻訳ドキュメントをホストする提案が受理されました。
PHP のドキュメントのように言語切替のUIが用意されて、より多くの人が母語に翻訳されたドキュメントにアクセスできるようにしていくことが目標です。
docs.python.jp で公開している日本語訳も、準備が整ったら docs.python.org に移管していくつもりです。
PEP 538 -- Coercing the legacy C locale to a UTF-8 based locale
1月号で紹介した C locale において UTF-8 を使うための提案である PEP 538 と PEP 540 ですが、私が BDFL delegate になり、先週 PEP 538 を受理しました。
BDFL とは言語仕様についての最終決定権を持つ Guido のことなのですが、実際にはすべてを Guido が決めているわけではなく、適切な人に委譲されることも多く、それを BDFL delegate と呼んでいます。
もともと PEP 538 と 540 には別の BDFL delegate がいたのですが、その方が時間が取れなくなったということで、 (PEP 538 の著者と PEP 540 の著者はふたりとも Red Hat の人なので) Red Hat と無関係な、議論に参加していた、非ASCII文字を日常的に使っているコア開発者として白羽の矢が立ちました。
PEP 540 の著者はしばらく別のことに忙しくされているのですが、 PEP 538 の著者の Nick Coghlan さんは活発に PEP を更新されているので、私も頑張ってレビューして、先週末に受理しました。
簡単に PEP 538 の動作を説明すると、 LC_CTYPE が C のとき、環境変数 LC_CTYPE に C.UTF-8, C.utf8, UTF-8 の3つを順に設定していき、最初に利用可能だった設定をそのまま使うというものです。成功すれば Python から利用する他のライブラリ (readline など) や環境変数を引き継ぐ子プロセスでもなるべく一貫して UTF-8 が利用できるようになります。
環境変数を上書きするとき警告されますし、上書きに失敗した場合も C locale を利用していることに対する警告が出力されます。警告を消したい人は、 locale -a コマンドで利用可能なロケールを調べて、 LANG か LC_CTYPE に C.UTF-8 や en_US.UTF-8 などのロケールを設定してください。
また、どうしてもどうしても C locale を使いたい、UTF-8を使いたくない人は、 LC_ALL=C を設定すれば、 C locale を利用できます。
古い Linux だと C.UTF-8 ロケールが利用できず、 LANG=en_US.UTF-8 や LANG=ja_JP.UTF-8 してしまうと LC_COLLATE なども影響を受けて sort コマンドなどの動作が変わってしまいますが、 LC_CTYPE はエンコーディングの指定に使われるカテゴリなので、 LC_CTYPE=ja_JP.UTF-8 などの用に設定しても man が日本語でマニュアルを表示したり sort が遅くなったり ls の順序が変わったりといった C locale ユーザーが嫌う副作用を伴わずに、 Python, readline, vim などで UTF-8 を利用できるようになります。
[Python-Dev] Is adding support for os.PathLike an enhancement or bugfix?
Python 3.6 で os.PathLike というインターフェイスが追加されて pathlib がずっと使いやすくなったのですが、標準ライブラリのAPIの中にはまだこれに対応していなくてパスを文字列で渡さないといけないものがいくらか残っています。
通常、 3.6.x ではバグ修正のみを行って機能追加は 3.7 になるのですが、 PathLike サポートの追加を 3.6.x で入れていいかどうかについて話題になりました。結論としては、ケースバイケースで x が小さい間はいくらか 3.7 からバックポートされることになります。
PEP 484 (static type hinting) の改良
PEP 484 update proposal: annotating decorated declarations
関数にデコレータを適用すると、シグネチャが変わる事があります。
# デコレート後の型は Callable[[str], ContextManager[DatabaseSession]]
@contextmanager
def session(url: str) -> Iterator[DatabaseSession]:
s = DatabaseSession(url)
try:
yield s
finally:
s.close()
このとき、デコレータ自体に type hint が書かれていたら、静的チェッカーはデコレートされた後の型は導出できます。しかし、型を書くのはプログラムの静的検査のためだけではなく、人間へのドキュメントという側面もあります。
導出後の型を宣言するための方法を追加して、それに矛盾がないことを静的チェッカーが確認できるようにしようということで、そのための構文・APIが議論中です。
PEP 484 proposal: don't default to Optional if argument default is None
今の PEP 484 では、def handle_employee(e: Employee = None): のようにデフォルト値に None を使っている場合、 e の型は暗黙的に Optional[Employee] になります。
この省略記法が他と一貫性がないなどの理由でやめようということになりました。
タイプ数は増えてしまうのですが、今後は明示的に Optional[Employee] と書かなければなりません。
明示的な簡略記法は 改めて議論 されることになりそうです。
PyCon US
PyCon US が開催されました。 YouTubeのチャンネルでたくさんの動画を見ることができます。
私はリスニングがダメで英語の発表はあまり理解できないのですが、 YouTube で字幕をオンにすると字幕が間違う部分（主にその発表に関する特別な単語）と自分が聞き取れない部分があまりかぶらないので、リスニングの訓練をしながら発表を見ることができるのでオススメです。
また、 Language Summit という、コア開発者を中心に招待された人だけが集まるイベントも PyCon の中で行われました。 このイベントの要約は LWN.net で閲覧することができます。（6/2まではサブスクリプションが必要）
例えば、先月号で Python 2 の命日について「最後の Python 2.7 をリリースした日が EOL」と書いたばかりなのですが、象徴というか目標となる日付として 2020年の PyCon US ということになりました。
また、 CPython を改造して GIL を取り除く実験的なプロジェクト "Gilectomy" についての現状報告も行われました。
