Iriedaさんがリンクしてますが、いちおう私の努力訳
First of all, I chose len(x) over x.len() for HCI reasons (def
__len__() came much later). There are two intertwined reasons
actually, both HCI:
まず、私がx.len()よりもlen(x)を選んだのはHCI的理由からです(def __len__()はもっとあとから来ました。2つ絡み合った理由がありますが、どちらもHCIからです。
… (もっと読む)(a) For some operations, prefix notation just reads better than
postfix -- prefix (and infix!) operations have a long tradition in
mathematics which likes notations where the visuals help the
mathematician thinking about a problem. Compare the easy with which we
rewrite a formula like x*(a+b) into x*a
こういう統一性のなさは、実用的なスクリプト言語ではよくあることです。
Pythonも最初から高度に(美しく)統一されたオブジェクト指向を目指していたわけではないため、楽にスクリプトが組めるよう、よく使われる処理はグローバル関数として実装されているものがあります。実用性のために統一性のない実装を許容していたのですね。
PHPなんかはその極端な例で、ほとんどの機能が標準関数で実装されており、関数の命名規則によって何に対する処理(arrayやstrなど)なのかがわかるように分類されています。PHPはWeb開発(バックエンド)でいまだにトップのシェアを誇るスクリプト言語ですので、あれこれ言われつつ、なんだかんだ標準の関数でどこでも使える方が便利に楽に書ける、というのは真理なのかもしれません。
Golangもそうなってますね、GoはOOPを推奨してないのでわかりますが、Pythonがlen関数な理由はこれだ!と言うのは思いつかないですね。
C++でtemplateで受け取ったもののサイズが欲しいとか、javaで配列とCollection別に関数作らなきゃならないのを見ると、
動的型付けで引数にどんな型が入ってくるか解らないなら、実装に左右されずlen関数でサイズを取得できるので、固定されてる方がいい気がしますね。
まぁ単純に、最初は文字列も配列も自分のサイズを持っていない実装で、builtinのlen関数で毎回サイズを計算していたとかな気がしますけどね。
あとはOOPを取り入れるつもりがなかったとか、Pythonのクラスってselfを引数に取ったり、抽象化にABCMetaとかいう謎のパッケージが必要だったり、どうにかなんなかったのか!と言いたくなる仕様多いですからね。
0 コメント:
コメントを投稿