『Dr.WEB メールデーモン』、MTA 用迷惑メール対策製品です！
最近になってようやく松江市にもヤマダ電器が開店したのだが、
開店セールで安かったので、妻と一緒に見に行った際につい衝動買い。
ただし、現物は今週まで届かなかった。
で、パンを焼いたらおいしかった。 もっとも以前から持っていた象印のものと極端に違うかというと自信がない。 しかし、米粉のパンが焼けるとか、餅がつけるとか付加的な機能に期待してしまうのであった。 今後が楽しみ。
ところで、またSANYO製品を買ってしまった。 うちは洗濯機も、FAXも、ビデオデッキも、布団乾燥機もSANYO製なのだ。 別にSANYOファンというわけではないはずなんだがな。
判官贔屓？
妹夫婦が引っ越しなので手伝いに行く...のだが、 妹がほとんど荷作りを完了していたのと、 運送業者が驚くほど手際がよかったので、 出番がない。
結局、少しだけ掃除の手伝いをしただけで終わった。 今まで何度か引っ越したことはあるし、他人の引っ越しを手伝ったことも何度もあるが、 こんなに手早いのは初めてだ。
近所の本屋で購入。まだ、2章までしか読んでいないが、
この範囲で一番感動したのは、レイアウトルール。
ブロック構造をインデントで表現しつつ、
式と分文の分離を発生させないというすばらしいルール。
13年前、Pythonの文法がこうだったら、私がRubyを作る動機のひとつはなかったろう。 ちなみにもうひとつの動機は、あのオブジェクトモデル。
うちの家電もSANYO（とSHARP）ばかりです。
理由はわかっています。安いから。それだけ。
「安いから」ですか。うちは「餅もつけるから」とか「横置きドラム式だから」、「2倍速再生が出来るから」とか別の理由があるものが多いように思います。役に立ってないものもありますが。
まあ、「変な機能がついてるわりに安かった」ってことなんでしょうけど。
> 式と分の分離
式と文の分離、のtypoでしょうか?
その通りです。直しておきました。ありがとうございます。
> ブロック構造をインデントで表現しつつ、式と分文の分離を
> 発生させないというすばらしいルール。
レイアウトルールと、式と文を分離するということは独立した話だと思うのですが、どういう意味なのでしょうか？Pythonの文法でも、インデントされた式の並びが単に最後の式の値を返すなどとすれば文と式を区別する必要は無いですよね？
本当に区別する必要はありませんか？
なぜPythonのlambdaがひとつの式しか書けないのか、そこには理由があると思いますよ。「たまたまguidoがそうしたかった」という以上の。
区別した方がより自然な文法であるかもしれませんが、現在のPythonの文法において、文と式を区別しなければならない必然性は思いつきませんでした。また、Pythonのlambdaがひとつの式しか書けない理由については、複雑なlambda式が可読性を低下させることを懸念したのではないかと個人的には思いますが、本当のところはわかりません。まつもとさんご自身はその理由について、どのように考えておられるのでしょうか。
じゃあ、関数引数を二つとる関数呼出しを現在のPythonの文法で実現できますか？
あ、現在の文法では出来ないのは明らかなんで、「現在のインデントルールで」に言い換えたほうがよいですね。
より正確には「lambdaがブロックを受け付けるようにPythonの文法を変更したとして(lambdaの値は最後の式の値)、その場合、現在のインデントルールのままではふたつ以上のlambdaを含む「式」を記述できません。私はそれがPythonが文(ブロックを含み、値を持たない)と式を区別している最大の理由だと思います。
うーん。やっぱりよくわかりません。例えば、関数引数を二つとって、両者を合成した関数を返す関数composeを考えたとき、ブロックを本体に持つlambda式二つを渡すような呼び出しは、現在のPythonのインデントルールでも次のように書くことができると思うのですが、何か間違っているでしょうか(A,B,C,Dは何らかの式)？
f = compose(
lambda x:
A
B
,
lambda x:
C
D
)
コンマの位置がインデントルールを破ってると思いますが。
でも、現在のPythonでも、以下のような式は書けるわけですから、もし上の式がインデントルールを破ってるなら、以下の式もインデントルールを破ってることになると思うのですが。また、
http://www.python.jp/doc/release/ref/indentation.html
を参照してみても、特にインデントルールに違反しているようには見えません。
f = compose(
lambda x: x + x
,
lambda x: x * x
)
これは「カッコの中では改行が意味を持たない」ルールが適用されているのではないかと。要するに
compose(lambda x:x+x, lambda x:x*x)
と同じことでしょう。ところがlambdaがブロックを許すと、ふたつ並べる場合にどこまででブロックが終わるのか明示するのは難しいし、仮にできたとしても大変美しくないです。
Haskellのようにインデント形式でも(ブレースを使って)範囲を明示する形式でも書ける、というルールにするのでなければ、ブロックを含む「文」は式の一部になれない、というルールにせざるをえなかったのでしょう。
そのことはlambdaにブロックを持たせようとしたPEPがすべてrejectされた経緯からもうかがうことができます。
> これは「カッコの中では改行が意味を持たない」ルールが適用
> されているのではないかと。要するに
> compose(lambda x:x+x, lambda x:x*x)
> と同じことでしょう。ところがlambdaがブロックを許すと、
> ふたつ並べる場合にどこまででブロックが終わるのか明示する
> のは難しいし、仮にできたとしても大変美しくないです。
了解しました。確かに、そういうことならば、単純にインデントによって複数行(式)lambdaを表現するのは問題がありそうです。あと、「カッコの中では改行が意味を持たない」ルールについては、
http://www.python.jp/doc/release/ref/implicit-joining.html
にちゃんと書いてあったのに、見落としていました。すみません。