Python普及しろ協会に入会したい

この記事はタナイ氏によるPython滅ぼす協会に入会したいを読んでから執筆したものです。

この記事の趣旨はPython滅ぼす協会に入会したいに対する反論という形をとりながら、タナイ氏により「バカの言語」と揶揄され、「使ってエンジニアを名乗るというのは」「滑稽」とまで言われたPythonの立場を再考することです。

追記
本記事は「Pythonはこれだけ優れた言語だからみんな使おう！」というものではなく「言うほど酷くないと思うよ」程度のものです。
型アノテーションがあるからと言って静的型付けを軽視しているわけでもなければ、map関数をもってmapメソッドを不要だと言っているわけでもありません。
この記法は嫌い〜この記法が好き〜と表明することは個人の自由ですが、同様に「この記法は実はこういう意味があって〜」という意見があればそれを聞いた上で、物事を判断して欲しいです。もちろん、聞いても意見が変わらなければそれで結構です。僕と価値観や重視する点がちょこっと異なるだけです。

追記2
言語には向いている用途とそうじゃない用途があります。
Pythonが好きな筆者でさえ、大人数のエンジニアが関係するような開発や、リテラシーが低めのエンジニアが居るような複数人開発ではPythonを選定することは多少チャレンジングだと考えています。
逆に、リテラシーの高いエンジニアが少数でスピード感を持って開発したい時やAIに関する開発、書きなぐりのコードを作りたい時や初学者に教える時、Pythonは良いチョイスだと思います。
そういった向き不向きを踏まえてどの言語を使うべきか考えるのも我々の仕事であり、言語を滅ぼすことは少なくともその範疇には含まれていないはずです。

追記3
筆者はPythonが好きですが、何でもかんでもPythonでやればいいじゃんとかは全く思っていません。言語仕様の全てが好きなわけでもありません。
List.mapが欲しいし、定数はないよりある方が便利だし、アロー演算子も好きです。だからと言って、List.mapを追加しない選択をしたのはバカだ！とか、定数がないからゴミだ！とかlambdaはダメだ！という話にはならないんじゃないの？と思います。
そういう意味で「彼らにも一定主張があって、それは一理あると僕は思うよ」というのをPythonの肩を持ちながら述べています。

動的型付け言語も進化している

普段からDartやTypeScriptなども書いている筆者にとって「型というガードレールもシートベルトもなしで糞を撒き散らしながらする開発にはうんざり」という意見はわからないでもない。
しかし、本当にPythonは「型というガードレールもシートベルト」もなく、開発は「糞を撒き散ら」すものなのか。

型に問題があるコードの例

name_by_id: dict[int, str] = {}  # warningが出る場合があるが(リテラルで記述できるよ！)という内容なので無視できる
name_by_id[1] = 'python'
name_by_id['ruby'] = 2  # まともなIDEならwarning


def greet(name: str) -> None:
    if not isinstance(name, str):
        raise TypeError(f'name must be str: got {type(name)!r}')
    print(f'hello {name}')


greet('python')
greet(100)  # まともなIDEならwarning

ここ数年でPythonの型アノテーションは劇的な進化を遂げてきた。TypeAlias, Union, Genericsさえもある。
「貧弱な型ヒント、しかも書いたところで大した効用もない」という部分に関しては、まったく同意しかねる。

Pythonのdictは型を指定するものではないのでエラーにはならない。しかし静的解析ができる範囲で、早期に問題を発見することができる。
ツールで言うと、mypyやpyrightという非常に優秀な型チェッカーも存在する。

mypyでの型チェック

└> mypy sample.py
sample.py:3: error: Invalid index type "str" for "Dict[int, str]"; expected type "int"
sample.py:3: error: Incompatible types in assignment (expression has type "int", target has type "str")
sample.py:13: error: Argument 1 to "greet" has incompatible type "int"; expected "str"
Found 3 errors in 1 file (checked 1 source file)

「十分に型を記述して型チェックも入れたPythonコードをmypyでチェックして実行する」ことと「十分に型を記述したTypeScriptコードをJavaScriptにトランスパイルして実行する」ことの間には、「発想自体がどうかしている」という程の差が果たしてあるのだろうか。
個人的には、ある言語(そもそも直接のRuntimeがないのだからそこにあるのはプログラミング言語というより、言語仕様ではないか。この言い方だとllvmやアセンブリを無視しているように聞こえるかもしれないが、言いたいことは伝わると思う)から別の言語にトランスパイルする過程での問題を過小評価しているといわざるを得ないと感じる。

確かに一部の古いライブラリには型アノテーションが不十分、あるいはまったくないものも存在する。
それらを使う場合には、ドキュメントを読み解いて自前でアノテーションを付けて型チェックを挟むことなども必要になるだろう。おかしな型アノテーションがされていればそれを上書きすることさえある。

ただし、ほとんどの場合においてそういうことはあまりない。
開発で普通に使われるようなライブラリはたいていしっかりとアノテーションがつけられている(コミュニティが大きいPythonだからこそ、こういった対応も早い)し、つけられていなくても優秀なIDEが自分で型を解析してくれたりする場合が多い。

Pythonが型安全だ！とか静的型付けと変わらない！と言っているのではなく「それほど混沌としたものでは無いのだから、厳格さの重要性と照らして問題ない場合にPythonを選ぶのは理にかなっているだろう」という主張だ。

結局のところどんな言語を使おうと、ほとんどの開発はいかに anyやunknown 型と戦うかという話になる。
WebAPIからJSONを取ってくればresponse bodyのbytes[](意味のあるデータ列だということを信じてはいるが、この時点では実質any。如何なるデータもPC内部ではただのバイナリ)をstringにし、パースしてMap<any, any>(あるいはMap<[str, number], [str, number, Array<self>, self]>とか？細かい仕様を見て書いてはいない)を得ることになるし、SQLで select age, name from users; を叩けば anyをTuple<integer, string>に型変換することになる。もっと複雑な処理をSQL文でやれば、プログラミング言語が提供できる型安全性からさらに離れていく。(少なくとも僕の知っている全ての)ORMには限界がある。どっかの段階で、生SQLという選択肢を選ぶ必要が出てくる。

完璧な型安全性などはないのだから、みんなどこかでanyと戦っている。

実務的な範囲で言えば、IOに型が付かないからと言って困る(型の安全性を疑う)場面はそうそうないだろう。しかし、そういう裏側をラップしてくれている存在がいて、そのうえで型安全な場所が提供されているということは意識した方が良いだろう。
Pythonでも、一部のアノテーションがついていないものに自分でしっかりアノテーションを付ければ、自分だけの型安全(と思える快適)な聖域が作れる。

どこから安全かという違いはあるにしろ、シートベルトをいつからどれくらいきつく締めるかは、プログラマ次第ではないだろうか。

ちなみに筆者はmypyなどのツールは普段使っていない。PyCharmくんは優秀なので。

シンタックスがキモいらしい

Python滅ぼす協会に入会したいによると、筆者のタナイ氏は少なくとも以下のsyntaxをキモいと感じているそうだ。

1. map(lambda x: y, some_list)
2. 通常のif文はif then else だが、式は 1 if x else 0
3. some_dict.some_key ではなく some_dict["some_key"]、{foo: number, bar: string} を定義するためだけに TypedDictをimportする必要がある
4. a = 10が文であり式ではない。その影響でa := 10という構文がある
5. 無名関数が lambda 引数: 返り値
6. &&や||ではなくandとor
7. 定数が定義できない

結構多い

1. map(lambda x: y, some_list)

「配列に対して操作を加えていきたいのに、記述位置を戻る必要がある。
戻らずに書き下せるように、適用順を変える演算子だとかモナドだとかHaskellの爪の垢を煎じて飲ませたい。」

Pythonは全体的な設計思想として、便利そうだからといってポンポンと機能を追加したりはしない。
このmap関数(やfilterなど)は純粋な「高階関数」という概念を表しているに過ぎず、こういうsyntaxでmapを提供している言語は多く存在する。高階関数(処理, 対象)というsyntaxは珍しくもなんともないし、そもそもはそういうものだ。
タナイ氏が「爪の垢を煎じて飲ませたい」と言っているhaskellでさえ

map func list

というsyntax(というか関数だが)を提供している。

Pythonはその思想の体現である『The Zen of Python』で"There should be one-- and preferably only one --obvious way to do it."(明白なやり方が ~できればたった1つだけ~ あるべきだ)と言っている。

高階関数が既にあるなら別にlistにmapメソッドをはやす必要はない。やりたいなら、自分で拡張すればよい。という考え方だ。
例えばGolangではよりシンプルにfilterやmapすらない。Pythonの作者のGuidoとしては、そこまでシンプルにしすぎるのはやりすぎで "practicality beats purity."(実用性は純粋さに勝る) から、関数は作ったのかもしれない。

さらに言うなら、mapやfilterをチェイン(Pythonではネストになるが)したいならそれぞれの処理ごとに変数に入れたり、for文を使えばよい。
無理に頑張る必要はないのだから。

この記事の筆者は、Array<T>のメソッドとして定義されているmapメソッドも好きだ。TypeScriptなどを書く際には楽しんで使っている。
しかし、それはmap関数を否定する材料にはならないと考えている。

2. 通常のif文はif then else だが、式は 1 if x else 0

「冗長で、醜く、プログラマのメンタルモデルに一致しない。」とタナイ氏は述べているが、これは"日本語話者エンジニアである自身のメンタルモデルに一致していない"と言い換えていただいた方が良いかもしれない。

PythonはそのSyntaxを英語に寄せており、可読性を重視している。英語においては"A if condition. otherwise B"という言い方を普通にするので、読みやすさという観点でこれにあっているのだ。
condition ? A : Bが読みやすい(分かりやすいと感じる)のはこの記法に慣れているからであって、この記法に慣れている人間よりも英語に慣れている人間の方がはるかに多いのだから、英語に寄せるという設計思想である以上メンタルモデル云々はPythonの文法を否定する材料にはならない。

文がthen if elseじゃないのは、そりゃそうだという感じだ。conditionと値の距離が近い式と違って、文は遠い。
ifを先に持ってくるのが実利に勝るし、何よりブロックの開始を意味するsyntaxを増やさなくてはならない。Pythonは、むやみやたらにそういうものを増やさない。

3. some_dict.some_key ではなく some_dict["some_key"]、{foo: number, bar: string} を定義するためだけに TypedDictをimportする必要がある

これは根本からタナイ氏が間違っている。
some_dict.some_keyをTypeScriptでできるから～という流れで記述されているようだが、そもそも.some_keyは辞書(TypeScript/JavaScriptでいうMap)のゲッターではない。
TypeScriptでの構文は

const map = new Map<string, string>();
map.set('key', 'value');
map.get('key');

である。

const map: CustomMap = {
  key: 'value'
}
interface CustomMap {
  key: string;
}
map.key

として定義できるものを辞書と言っているのかもしれないが、これはただのObjectだ。
つまり、Pythonでこれに等価なものはdictではなく、classのインスタンスである

#~#~#~#~#~#~#~# class #~#~#~#~#~#~#~#
class CustomMap:
    def __init__(self, key: str):
        self.key = key
    def __repr__(self) -> str:
        return f'CustomMap(key={self.key!r})'

>>> CustomMap(key='value')
CustomMap(key='value')
>>> CustomMap(key=1)
CustomMap(key=1)

#~#~#~#~#~#~#~# dataclass #~#~#~#~#~#~#~#
# 公式のdataclassを使うとより簡単に表現できる
from dataclasses import dataclass
@dataclass
class CustomMapWithDataclass:
    key: str
>>> CustomMapWithDataclass('value')    
CustomMapWithDataclass(key='value')
# IDEではwarningを出してくれるし、mypyだとエラーが出る
>>> CustomMapWithDataclass(key=1)
CustomMapWithDataclass(key=1)


#~#~#~#~#~#~#~# pydantic #~#~#~#~#~#~#~#
# pydanticを使うと、castさせたり、エラーを吐かせたりが簡単にできる
from pydantic import BaseModel
class CustomMapWithPydantic(BaseModel):
    key: str
>>> CustomMapWithPydantic(key='value')
CustomMapWithPydantic(key='value')
>>> CustomMapWithPydantic(key=1) 
CustomMapWithPydantic(key='1')


#~#~#~#~#~#~#~# pydantic(strict) #~#~#~#~#~#~#~#
from pydantic import Field
class CustomMapWithStrictPydantic(BaseModel):
    key: str = Field(strict=True)

>>> CustomMapWithStrictPydantic(key='value')
CustomMapWithStrictPydantic(key='value')
>>> CustomMapWithStrictPydantic(key=1)
pydantic_core._pydantic_core.ValidationError: 1 validation error for CustomMapWithPydantic
key

classのインスタンスであれば

class CustomMap:
    def __init__(self, key: str):
        self.key = key
    def __repr__(self) -> str:
        return f'CustomMap(key={self.key!r})'

>>> custom_map = CustomMap(key='value')
CustomMap(key='value')
>>> custom_map.key
'value'
>>> custom_map.key = 'next_value'

とできる。

TypedDictをimportする"必要"は一切ない。classを使えばいいだけだ。
VSCodeではMapにマウスオーバーすると要素が表示されるのか？と思ったがそんなことはなかった。そりゃそうだ。辞書はランタイムでkeyも変わるのだから。

この項目に関しては、まったくの的外れである。

4. a = 10が文であり式ではない。その影響でa := 10という構文がある

この言い分には2つの視点がある。

a = 10 が文であり式ではない

これは、個人的に良い言語仕様であると思う。 a = 10 が 10となるような式だった場合

これはC言語

const SECRET = 'secret_key';
const validateKey = (key: string) => {
    return key = SECRET;  // == にすべきところをtypoしてしまった！
}
if (validateKey('wrongKey')) {
    console.log('correct key!')
} else {
    console.log('wrong key...')
}
# output:
# correct key!

となってしまう。多くのプログラマーが =と==を間違えて時間を溶かしてしまった経験があると思う。
これを防ぐために、Pythonでは

>>> a = 1
>>> if a = 1:
  File "<stdin>", line 1
    if a = 1:
       ^^^^^
SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='?

となっているのだ。
C言語などにおける

int a, b;
a = (b = 10);

は

a = b = 10

とできるので、そもそも式にする必要はない

a := 10という構文がある

これは

value = heavy_duty()
if value:
    # valueはここでのみ使う

# 正規表現
regex_match = pattern.search(data)
if regex_match is not None:
    # regex_matchはここでのみ使う

# read
chunk = file.read(8192)
while chunk:
   process(chunk)
   chunk = file.read(8192)

といった処理を

if value := heavy_duty():
    # valueはここでのみ使う

if (regex_match := pattern.search(data)) is not None:
    # regex_matchはここでのみ使う

while chunk := file.read(8192):
   process(chunk)

と簡略化するためだけのsyntaxである。
トップレベルで使えないのは、=が使えるからだ。
Pythonは新規機能を追加するのに至極消極的である。この構文も、Guido van Rossumがこの構文を気に入らなければ、十中八九却下されていただろう。その中で、トップレベルで(=と同じように)使えないようにしたのは、
"There should be one-- and preferably only one --obvious way to do it."(明白なやり方が ~できればたった1つだけ~ あるべきだ)からだろう。

ただし

a = (b := 10)

という構文はトップレベルでも有効だ

5. 無名関数が lambda 引数: 返り値

これが「まだるっこしい」かどうかは、個々人の価値観次第だ。タナイ氏がオランダ人じゃないからそう感じるのかもしれない

個人的には、嫌いじゃない

6. &&や||ではなくandとor

この言語は、英語話者が直感的に理解できるようにという思想で作られている。
&&や||より andとorの方が、この視点で言えば良い。少なくとも、&と&&のどっちがbit演算子でどっちが論理演算子かを迷う必要はない。

この"迷いがない"というメリットに対するデメリットが「記述量が増えている」なら、正直無視できる

7. 定数が定義できない

Pythonには一部「真の定数」が存在するが、ユーザはそれを作成することはできない。

ユーザができることはせいぜい定数として命名しlinterを通して再代入を防ぐように呼び掛けたり、classのgetterやsetterを頑張って使って定数っぽいものを作ったり、アノテーションを通してFinalと示してIDEやツールで代入を防ぐことくらいだ。

しかし、別にそれで特に問題はないだろう。

定数を上書きできたとして何に困るのか、いまいちわからない。
上書きできるのだから定数に依存するテストが書きやすい。
プログラマが上書きしないようにと考えていれば、本来定数なんて上書きするものではないのだから。
もししてしまうなら、それは定数がないことより、そんなコードを書くことの方が問題だ。

Guidoは"We're all consenting adults here"(Effective Pythonには「みんないい大人なんだから」と書いていたような気がする。完全にうろ覚え)と言ったらしい。
各々が各々の責任において「この定数を上書きするぞ！」と決めたのなら、それをやめさせる理由はない。

競プロ以外に正しい使い道がないのか

筆者は大昔に競プロをPythonでやっていた。
水色になった直後に業プロ(業務プログラミング)に目覚めて辞めてしまったが、競プロをPythonでやっていたのは結構良い選択だったと思っている。

30行くらいのコードを書くシーンでは使いやすいが、「そんなノリで通常の開発をしたら早晩詰む」という意見がある。
果たしてそうなのか。

答えは、Instagramとか見ていただければよいと思う。
いい例だけを取り上げて「Pythonは大規模開発にも向いている！」というつもりはない。大規模開発にもっと向いている言語はたくさんある。
ただし、「一般の開発に使うと早晩詰むか」と聞かれれば「あなた次第だ」というほかない。

Jupyter Notebook(や Google Colaboratory)についても、向き不向きがある。
機械学習をやっている時、Jupyter Notebookの開発体験は非常に良かった。同じ用途においては、他の人にも同様のものを勧めるだろう。
しかし、それはほぼ書き捨てで様々な検証を行うためのものだ。
あくまで"ノートブック"だし、"コラボ"で"ラボラトリー"(予想である)を運用するための物であって、これを保守対象とするのは、渡す側と受け取る側の問題だ。
まだ言い続けるなら、TypeScriptのプレイグラウンドを保守対象として渡すことも辞さない。

ちなみに筆者も、保守対象として Jupyter Notebook を受け取りたいといえば嘘になる

教育現場でPythonが選択されているのは不幸なのか

不幸ではないと個人的に思う。

「国語の教科書の代わりに素人が書いたケータイ小説を渡しているようなもの」という意見もあるがでは逆に、小学1年生に『人間失格』を読ませるのか。
いや、そもそもタナイ氏の例もそれに対する上記の私の反論も正しいものではないだろう。
さしずめ厳密な型付けをした型安全で記号が多い言語が「文語体の論文」で、動的型付けで英語のように「記述量が増えている」言語が「文語体の小説」とか言った方が近いかもしれない。「素人が書いた」かどうかは全くもって言語うんぬんとは異なる話である。
研究者を育成したいなら小説だけを読ませるのは問題だ。しかし、日本語のとっかかりに美しい口語体の小説を読ませ、慣れてきたうえで望むならば論文でも読ませてあげるのが流れというものではないか。

Python滅ぼす協会に入会したいの筆者と同じような勘違いをされている方も一部いらっしゃるかもしれないので一応述べておくと、実はプログラミング教育の目的はプログラミング言語の習得それ自体ではなく、IT時代を生き抜くためにロジカルな思考を身につけ、活用する術・態度を育むことである(筆者は以前文部科学省のPython教材に関する記事を書いたことがあり、教材・資料を読み漁った)。
口語体でも文語体でも、国語の教科書だろうとケータイ小説だろうと、学んでほしいのはその裏側にある思考なのだ。

プログラミング教育の目的はエンジニアの育成ではない。

プログラミング教育現場で使用する言語に求められる要素は

• 実際に活用可能
• さまざまな環境(win, mac)で動作する
• アルゴリズムをもとに、簡単に記述ができる

などだ

型が～とか、&&だandだ～とか言っているうちは、何もわかっていない・視野が狭いということだ。

逆にどの言語なら良いのだろうか？
TypeScript(JavaScript)は型の暗黙の変換による罠が多すぎて初学者には不向き
Javaはいわゆる「おまじない」が多すぎて不向き
Cの型システムは子供には難解すぎるかもしれないので不向き
どの言語も(Pythonももちろん含めて)否定しようと思えばいくらでも出来ると思う。

lambda arg: returnより(arg)=>respが、A if cond else Bよりcond ? A : Bが完全に優れていて、それぞれ前者を「まだるっこしいシンタックスなのも癇に障る」とか「冗長で、醜く、プログラマのメンタルモデルに一致しない」と思う程記号でプログラミングがやりたいなら、Brainfuckでもやっておけばよい。