#ref(http://www.python.org/images/python-logo.gif)
[[Python Programing Langage>http://python.org/]]
-&color(green){Pythonista}; = %%Python教の狂信者%% Pythonを好んで使う人々のこと
-※こんなページタイトルですが、'''&color(green){Pythonista};とは直接関係ありません'''。単にプログラミング言語Pythonの、一風変わった特徴／哲学の特集です。
-このページの参照数 &counter; 回
#contents
*インデントブロック is not アンフリーフォーマット
インデントブロックは、ABC言語から受けついだPython最大の特徴としてよく紹介されます。そしてこの特徴を以って、古参のベテランプログラマの方々はCobolなどのフォーマット固定言語を彷彿させ、難色を示すという話を時々聞きます。
実際から言えば、Pythonはほぼフリーフォーマットです。ブロックのインデントは強制されますが、式はいくらでも長くできますし、パーレン（丸括弧）でくくれば、行もかなりファジーに設定できます。
何より、強制されなくともブロック構造はインデントされて書かれるのが普通なので、むしろ「ブロックに括弧を書かなくて良い、手軽な言語」として考えていただいたほうが正確かと思います。
ただ、TABによるインデントはトラブルの元なので、ホワイトスペースによるインデントをお勧めいたします。
#comment
*どこにでもあるelse？
if文にelse節があるのはあたりまえ。elifも、case文と同様と考えればそんなに珍しくもない。でも、for文やwhile文にelse節が付けられるのはPythonぐらいでしょう。しかもこのelse節は「breakせずに正常にループが終了したら起こる」のです。
理屈としてはこうです。if文の条件式が偽になった時にelse節が実行されます。forやwhileは、条件を満たさなくなった時にループを抜けます。ゆえに、「条件節を満たさなかった時にelse」は理屈には合っています。しかし、「正常にループが終わるとelse(～でなければ)」というのは、語感的に微妙な気がしないでもないですね。
#comment
*Lambdaはお一人様のみ
Pythonのラムダ文と呼ばれる文法は、lambdaキーワードによって、式を関数に変換して返すことが出来ます。ただし、defキーワードによる関数定義と異なり、ラムダ文の中には式しか書けません。Pythonでは代入は式でなく文ですから、ラムダ文によって記述できる関数は、かなり限定的なものになります。
ラムダ文が式にしか適用できないのは、ラムダ文の中であまり複雑化しないように、という配慮らしいのですが、その結果、数学で言うところのλ式に近い雰囲気になっている（当然、本来のλ式には代入などない）ともいえます。
ラムダ文は、名前にバインドされない無名関数を作ることによく使われますが、別に代入文を使って名前をつけることも可能です。むしろ「関数オブジェクト」を記すリテラルと考えていただいたほうがいいかもしれません。
#comment
*文は式ならず
文と式の区別の無い言語の信奉者には、Pythonの「文と式の区別」は、前に挙げた「ブロックインデント」とともに、異端審問のように糾弾されるネタの一つです。Pythonでの式文(lambda文を含む)以外の文は、代入文、print文、exec文、for文、if文、while文、クラスや関数などの定義文、その他の例外文関連でしょうか。
このうち、print文とexec文はPython3000では関数に変更されますし、if文は条件付評価式(Conditional Expressions)でかなりのことが書けます。for文も内包表現でそして、どんな文もdef定義で囲ってしまえば関数⇒式になってしまいます。各文を無理やり式にする必要は無いと思いますし、そのメリットもあるんだか無いのだか、結構理解しにくいです。
では、文と式を分けることにメリットはあるのか……これは、代入(=)と比較演算(==)での単純ミスを起こさないため、ということがよく例に挙げられます。その他にも、式で表現できるということは、逆に複雑な式が書けてしまうという「悪しき欲求（ダークフォース？）」を呼びます。その抑制のためにも、文法で禁止してしまうのも一つの方法ではないのかな、と思います。
#comment
*なんでもimport？
Pythonでは、プログラムを終了するにも、コマンドパラメータを取得するにもインポートが必要です。他のスクリプト言語では、面倒なパッケージインポートなどをせずとも使える組み込みツール（関数／手続き）がてんこ盛りなのに、Pythonはそれに比較して意外と少ないです。
これは、逆に考えれば自由に使える名前が多い、ということです。名前空間は混雑しやすいですから、必要なものだけを導入し、すっきりと記述できる、という方針でもあります。また、インポートするパッケージ／モジュールを見ることで、スクリプトの性質が理解しやすくなるという点もあります。
どうしても面倒だという方は、よく使うツールを自分用に登録したモジュールを用意されることをお勧めします。
ただし、未だにimport sysでsys.exit()を呼び出してる方については、（多分2.5以降は）quit()で一発で終了できますので、「Pythonはインポートしないと終了すらできない」という濡れ衣を着せるのは止めてください（まぁ、以前は実際そうだったのだけど……）
#comment
*わが道を行く「オブジェクト指向」の考え
C++に似ているようで、そうでなし、さりとてSmalltalk風かというとそうでもなし。そもそも、オブジェクト指向と銘打ってる割には、カプセル化なんて全然気にしないし……Pythonのオブジェクト指向プログラミングのスタイルは、かなり独特です。
全体としての書き方は、C++やJavaに似てますが、演算子のオーバーロードはメソッドフックを使って実現します。
クラスやクラスインスタンスは、改造改変が自由自在であり、それで暴走したって自己責任です。
また、意味の無い多重継承に至っては……パーツを組み合わせる合体クラスでも作るのでないかぎり、何に使うのか意味不明です（has-a関係をサブクラスで表現していいのかしらん？）
selfポインタを使って外側から内側をイジるような気持ちの悪いスタイルに至っては、非難ごうごうです。
でも、わが道を行くPython
**みにくいアヒルの子
オブジェクト認識の基本は「[[ダック・タイピング:http://ja.wikipedia.org/wiki/%E3%83%80%E3%83%83%E3%82%AF%E3%83%BB%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B0]]」で、それが故に「コードを書くときは注意が必要だ」とかウィキペディアに書かれていたが、よほどの無謀なチャレンジャーでない限り、リスクを回避すべき実用的なプログラムに、普通このダック・タイピングの特徴は使うわけがない（素直にターゲットオブジェクトを継承して、隠蔽なり拡張なりして使えばいいのだから）
Python3000になって、関数やオブジェクトが受け取るオブジェクトの指定ができるようになったが、これ、単なるアナウンス用だけであり、強制力は全く無いそうな……
#comment
![[PukiWiki]](skin/modernskin/logo.png "[PukiWiki]"){kind=logo}
