はじめに
Python言語サミット2020が4月の15日、16日の2日間で開かれました。これはPython実装の開発者（本家のCPythonに加えてPyPyなども）が集まる会議で、単にプレゼンし合う場というよりは言語本体や標準ライブラリの現状や今後に関する議論をして合意を目指すという会議とのこと。
今年はコロナウイルス蔓延の影響で、ご多分に漏れずオンライン開催となったそうですが、2日間の議題を見るとなかなか興味深いものが並んでいます。
- 全ての文字列をf文字列にする
- CPythonのパーサーをPEGベースの物にする
- (C)Pythonの仮想マシンの形式仕様記述
- 実装非依存のC言語拡張API
- CPythonのドキュメンテーション保守の変革
- ライトニングトーク
- pip, PyPI そしてパッケージングに今後何を求める？
- 「マルチコアPython」プロジェクトの失敗を振り返る
- Pythonの型導入の今後の方向性
- CPythonのコア開発のワークフロー改善活動アップデート
- モバイルプラットフォーム上のCPython
このなかで、1つ目の「全ての文字列をf文字列にする」というのを取り上げて、このブログ投稿を元にどんな議論がされたのかを軽くまとめてみたいと思います。
f文字列とは
まず議論に入る前にf文字列とは何かをおさらいしておきましょう。f文字列はPython 3.6で導入された機能で、文字列の一部に変数や式をいれておき、それを実行時に置き換えるというものです。
例えば
>>> x = 1
>>> print(f"xの値は{x}です")
xの値は1です
となります。f文字列が導入される前までは似たようなことをしようとすると
print("xの値は%dです" % x)
としたり、
print("xの値は{}です".format(x))
としたりしていました。どちらにしても、変数で置き換える場所と変数を指定する場所が分かれていてわかりにくく、バグが起こりやすい部分でした。これがf文字列の導入で一気に楽になりました。
他の言語でも、例えばJavaScriptだと、
let x = 1
console.log(`xの値は${x}です`)
と書けたりしますし、Ruby, Scala, C#などでも同様の機能があるので時代の潮流に乗ったということですかね。
なお、f文字列の機能はPython 3.8で少し拡張されていて、例えば
>>> x = 1
>>> y = 2
>>> print(f"{x=}, {y=}, {x+y=}")
x=1, y=2, x+y=3
とできます。つまり、{}の最後に=をつけることで変数や式の値だけでなく、変数や式そのものを出力に含めてくれます。ちょっとしたデバッグする時に便利なので覚えておいて損はないかと思います。
Python言語サミット2020での議論
上記のようにとても便利なf文字列。これがあるのでPython2からPython3に上がって来た、という人もいるらしいのですが、多く使われるに連れて不満も出てきています。それを解決するための議論がPython言語サミット2020の1つ目の議題となっています。議題を提出したのは元々f文字列導入のためのPEPを2015年に書いた Eric Smithさん。
ここで取り上げている問題というのは、これ。
>>> x = 1
>>> print("xの値は{x}です")
xの値は{x}です
わかりますでしょうか。「あ、文字列の前のfを付け忘れた (^^;」というやつです。
この間違いを避けるために、変数置換があろうがなかろうが全ての文字列の前に fを付ける、というプログラマーを彼は見たことがあるそうです。そこで彼の提案は
「文字列をデフォルトでf文字列にする」
というものです。実際、f文字列を3.6で導入する時には最初はそういう提案だったらしいのですが、大きすぎる破壊的な変更ということで却下され、今のfを頭につける形に落ち着きました。
今回の提案は、fがついてもつかなくてもf文字列とする、そして追加で 「p文字列」というのを導入し、文字列の前にpがついていたらこれまでの文字列として扱う、というものでした。それによる性能面での低下もありません。
一方で発案者のSmithさんも幾つか問題があることわかっていて、例えばpという新しい文字列接頭詞を導入しないといけない。あと、結構大きな変更になるので
from __future__ import all_fstrings
という import文がある時のみこれを有効にするようにしたりしたくなる。まあでもそうするとなかなかこれを外すことができなくなるのでこの案は却下かなということになりました。
この提案に対して参加者から幾つかコメントが出ました。
Yarko Tymciurakさんからは「初心者に pって何でどうやって説明するの 」という質問がでました。Smithさんは「pって言語仕様をちょっと複雑にしちゃうよね」と認めながらも「実際にはpってそれほど使われないだろうし、説明もまあ自明じゃないですかね」と答えました。
何人かの参加者はこの変更に前向きで、Brett Cannonさんは「f接頭詞を無くすことは初心者にとってPythonを学ぶのが簡単になるだろう」とコメントしました。
Larry Hastingsさんは「PHPの文字列もこういう仕様だし、スクリプト小僧たちはとっても気にいると思う」と言いながらも、「でもこれって、『おっと、fつけるの忘れっちゃった』というのを避けるためで、それって別にすぐに気がつく間違いだと思うけど、それだけのために言語仕様の変更する？」と疑問を呈しました。
多くの参加者は、f文字列が最初からデフォルトだったら良かったということに同意しながらも、Paul Mooreさん、Guido van Rossumさん（Pythonの創始者ですね）などは益よりも害の方が大きくなってしまうことを懸念しました。そして、続きはMLで議論しましょうということでこの議題は終了となりました。
まとめ
個人的には f文字列をデフォルトにするのに賛成ですが、それほど簡単に行かないんだなと思いました。短いブログ記事でしたが、参加者の皆さんが様々な側面を考えながら慎重に言語仕様の変更を議論している様が垣間見れて良かったと思います。