Web　酒　肴

最近、諸事情で参加できないことが続いていたので、この第７回でなんとか巻き返しを図った。 結果、何とかP307まで読むことができ追いつけた。 が、内容はどの程度頭に残っているのだろう？ 文法的な内容は置いておくとして、自分なりに感じた感想を。

Pythonは全てオブジェクトである

どうも最近のバージョンからなのだと思うが、関数・モジュール・変数・クラス、それら全てがオブジェクトとして一意に扱うことができるように作られている。 JavaScriptと似たような感じなのだろうか？JavaScript詳しくないからわかんないけど。

例えば全てのオブジェクトは自分自身を削除する関数（__del__関数）を内部的に持っている。 そこでやっとわかったことがある。以前にも書いたが、どうしてdel関数が組み込み関数になっているのか。

よくあるパターンではリストの２番目の要素を削除するときは以下のように書くだろう。

list.del(2)

だが、Pythonの場合はこう書く。

del(list(2))

これに非常に違和感があったのだが、Pythonの思想上オブジェクトを全て一意に扱うことから、内部的に全てのオブジェクトは自分自身を削除する機能を持たせることにした。 つまりリストが自分の持つ要素を削除するのではなく、その要素自身が自分を削除するわけだ。 つまり、内部的にはこのようなことが起きている。

list(2).del()

これがあまり直観的ではないから別途組み込み関数にdelを用意したのではないだろうか。 多分そのはずだ。きっと。いや、でも間違ってるかも。まあいいか。

シンプルさを保つために意外に無理やり

Pythonでは外部から関数へのアクセスを制限するために、アンダースコア（_）を前後に２つずつつける。 先ほどの__del__関数もその一つであり、外部からその関数にアクセスすることはできなくなる。 しかし、その実装方法に驚いた。

内部的に別の名前の関数に変換される

というのだ。 つまり__del__関数は内部でhogehoge_delなどのように全く違う名前の関数になっている。 だから外部から__del__で実行しようとしてもそんな関数はないから実行できない。

でもそれって、偶然その変換後の名前を探し当てたら実行できちゃうってことなの？ まあ実際にはもっと探し当てにくい複雑な名前にしているのだとは思うし、当たったところで実行はできないのかもしれないけど、なんか無理やりだなぁと思った。

でもしかし、気持ちはわかる。 その変換後の名前を探してやろうなんて奴はめったにいないだろうし、そんなことをするメリットもよくわからない。 それなら、そんな機能を実装するのに一苦労するよりも現実的な解としては最適かもしれないからだ。 なんとなくRuby on Railsなんかの思想にも通ずるところがあると思う。

哲学を貫くJava、名より実を取るPython、いいとこどりのRuby、そんな感じだろうか。
（最近Javaの哲学はかなり揺らいでるとは思うけど。。）

guccyon企画の第２回

P67から読み始めて、先に帰らなくてはならなかったので一応P116まで読み進めておいた。 みんなは結局何ページまで読んだのだろう。 内容は以下。

• 条件分岐とループ
• 関数
• ファイル処理

Rubyとの比較で読んでしまうので似ている部分も多く、今回は特に気になるところはなかったなぁ。 リストの比較を == で行えることくらいだろうか。

>>> print [ 1, ( 1 + 1 ), ( 1 + 1 + 1 ) ] == [ 1, 2, 3]
True

まだ文法の基礎的な部分なので、差がつきにくいところでもあるんだろう。 結局プログラミング言語の差って、その言語を使う人たちのコミュニティの質に大きく左右されるようだから。 そういう意味では、Pythonを取り巻いているであろう色んな要素は非常に楽しみだ。

guccyonが「みんなのPython」の読書会を企画したので参加。 毎回、感想をどこかに書くというルールがあるので、ここで報告します。

今回は前置き部分は飛ばしてP11からP67まで読むということだったけど、気になったので前置きも読んでみた。 言語仕様的な特徴はこことか

Pythonのお勉強 - guccyonikki

ここに書いてくれているのでざっくり省略。

みんなのPython読書会#1 - かけだしプログラマの奮闘記

なので僕は気になったことを自分なりに分析し、自分勝手な答えを作って満足するという方法をとります。 まず、

del文ヤバイ

del文によって配列の要素とか変数そのものを削除できるみたいですが、何のために存在するのかわからない。 配列オブジェクトのdelメソッドでもいいはず。 組み込み関数のdel関数でもいいはず。 でもそのどちらでもなくて、なぜかdel文なのです。 扱いはif文とかfor文などと同じ。 なんでそんなの作ったの？ メモリは即座に開放されるの？それともガベージコレクションの対象となってしばらくは生き続けるの？ 本当に不思議な存在。

自分的結論

Pythonの作者（名前忘れた）は恐らくC言語でPythonを作ったのだと思うが、彼はC言語でできるけどPythonでできないことを作りたくなかった。 メモリを即座に開放したい、と思ったらCではそれができる。だからPythonもできなければいけない。 そしてこの処理はあまりにも特殊であるため通常の関数にはせず、あくまでdel文にした。 という予測はどうだろう？

タプルは美しい

聞きなれないタプルという言葉。 どうやら変更できない固定の配列みたいなもののことらしい。 配列として扱えるリストという組み込みデータ型もあるのに、なぜこれが必要なのか？ 不思議な存在だ。

自分的結論

とりあえず美しい。まず「タプル」という名前がなんかタプタプしてて美しい。その後にラ行の音を持ってくるあたり、かなりのバランスの良さが生まれると同時に、「プル」という、これまたプルプルした感じの響きまでくっつけた。美しすぎるネーミングセンス。

そしてタプルは変更不可というのも美しい。 だから辞書（ハッシュみたいなもん）のキーにも使えるとのことだ。
JavaのHashMapだと、変更可能なオブジェクトもキーに使える。なぜなら内部的にはオブジェクトの参照先アドレスをキーにしているからだ（多分、間違ってるかもしれないけど似たことをしてるはず）。

ということは、Pythonではそうではない、のではないか？あくまでキーに指定されたオブジェクトが参照する値を比較する。 キーはハッシュ化されるからキーが持つ値によってメモリ上の格納先も決定する。それが後から書きかえられたら都合悪いってことだろう。

辞書のキーであろうがなんだろうが、変数はあくまで中身の値で扱うという徹底した思想がある、のかもしれない。
だからこそ柔軟な言語になる、と言える気もする。
（推測ばっかだな）