井上 研一 私は基本的にxxxerというほど特定の言語が好きとかはないのですが、強いて言えばここ2年ほど仕事でCakePHPをずっと使っていたり、ブログがWordPressでテーマやプラグインを作っていたり、もっと前からちょっとしたWebツールを作っていたりしたので、まぁPHPerかなぁということにしておこうと思います。
そんな（とりあえず）PHPerが、胸を張って「xxxerだぁ！」と言える言語を求めて、（and 内輪の勉強会のためもあって）Pythonを3日くらい触ってみました。
今日は、その感想を書いてみようと思います。
前提
今回触ってみたのは、Python2.7です。既にPython3があるのですが、やっぱりPythonといえばGoogle App Engine（GAE）じゃないかということで、Python2.7にしました。（GAEでは現状、Python3が動かない。）
あと、WebフレームワークのPythonでの定番と思われるdjangoにも触ってみました。というか、djangoばかり触っていました。こちらのバージョンは最新の1.5です。
言語としてのPythonはすっきりスマート
私の周囲には、Pythonを言語として勧めてくる人がいるのですが、その彼の言うとおり、言語としては良いですね。
感覚的な表現になってしまいますが、書いていて、ストレスを感じることがないです。
PHPだと関数型の書き方と、オブジェクト指向型の書き方が入り混じっていたり、そもそもオブジェクト指向の実装に無理を感じるようなこともあります。（PHPもバージョンが上がるにつれて、その辺は改善されていると思いますが。）
そういう「無理」をPythonは感じません。
あと、Pythonの特徴といえばインデントが極めて重要な意味を持つことだと思います。ここは、私が最近CoffeeScriptを使っていて、インデントの構文に慣れが出てきていたので、特に違和感は感じませんでした。
関数（メソッド）の呼び出し時には、引数を括弧で括ることが強制されます。引数なしの時以外は括弧の有無はどちらでも良いCoffeeScriptと比べると、迷わなくて良いと思います。
from django.http import HttpResponse
のようなimport文の書き方は、最初は違和感がありました。でも、
from django.http import HttpResponse, Http404
という具合に、複数のクラスをインポートしたい時には便利だなと思って納得しました。
djangoはCakePHPやRuby on Railsとは全然違う
urls.py
Pythonでの定番Webフレームワークであるdjangoですが、同じMVCフレームワークとはいえ、CakePHPやそのインスパイア元であるRuby on Railsとはかなり違った印象を持ちました。
最初に感じた違いは、urls.pyの存在です。
<
pre><code class=”language-python””>from django.conf.urls import patterns, include, url
urlpatterns = patterns(‘foo.bar’,
url(r’^index/$’, ‘index),
url(r’^view/(?P
)
のように、URLとControllerのメソッドの紐づけをします。
CakePHPにはroutes.phpがあり、Railsにはroutes.rbがありますから、まぁ同じようなものだと言ってしまえば、そうかもしれません。
ただ、CakePHPやRailsには命名規約があって、それに従っていれば、実はあまりroutesをいじることはありません。でも、djangoの場合はチュートリアルの時点で、かなりかっちりurls.pyが説明されます。基本、urls.pyは自分で考えて書くものなのでしょう。
プロジェクトとアプリケーション
CakePHPやRailsではプロジェクトとアプリケーションに差はありません。というか、意識する必要がありません。最初に cake bake や rails new でアプリケーションを作ったら、あとはModel、Controller、Viewのディレクトリにそれぞれファイルを作っていくだけですから。
しかし、djangoの場合は、 django-admin.py startproject でプロジェクトを作って、その中でさらに python manage.py startapp でアプリケーションを作ります。
このプロジェクトとアプリケーションの違いが最初は、あれ？と感じます。
でも、ここで作ったアプリケーションを、他のプロジェクトにも持って行けるということを知ると（ここでurls.pyが効力を発揮する。チュートリアルでもちゃんと説明されている）、djangoすげーーということになりますな。
ただ、実際の開発においては、プロジェクトとアプリケーションをどのように設計するのか。その辺が非常に気になります。何かノウハウが集積されていたりするんですかね。
Modelについて
CakePHPの場合、先にDB定義して、そこからModelを作ります。CakePHP上では属性の定義がされず、DB定義が常に正という扱いです。つまりDB→CakePHPです。
Railsでは、マイグレーションファイルを書いて、そこからDBをマイグレーションします。こちらはRails→DBです。
djangoはこの区分でいえば、Modelに属性を定義して、DBにsyncdbするので、Railsに近い、django→DB方式です。ただ、いちどテーブルを作ると、その定義を変更してもsyncdbできない（つまりsyncdbできるのは最初の1回だけ）あたりは、Railsの柔軟なマイグレーション（その分、マイグレーションクラスでフォワードとロールバックの両方を定義しないといけないけど）と比べると、少し見劣りするかなと思います。
djangoでは、Modelを作るとそこからAdmin画面が簡単に作れます。ここで出来るAdmin画面は、いわゆるScaffoldとは違い、かなり気合いの入ったものになります。Modelの定義で日本語の正式名称を入れておくと、それも反映されます。大したものです。
ただ、これは逆に言うと、アプリの開発のベースとなる（本来の意味での）Scaffoldは出来ないということになります。この辺はフレームワークによる価値観の違いですかね。
まとめ
ということで、いろいろ書いてきましたが、今後もPythonを使ってPythonistaになっていくのか？というと、その辺はまだスッキリしていません。
というのは、Python2での日本語まわりの扱いが結構複雑だなぁ（実際、めちゃくちゃハマった）というのと、djangoの良いところは何となく感じるけど、いまひとつ採用を決断できないためです（趨勢のRails的なものとは違うし、それは古いってことなのではないか・・・）。
もしかしたら、Python3にして何か別のフレームワークを使ったら、スッキリするのかもしれません。でも、GAEが未だPython2であることを考えると、それも躊躇します。（Rubyが全盛の日本で、あえてPythonに行く理由の一つは間違いなくGAEの存在だと思います。）
今回、Pythonを触るきっかけとなった内輪の勉強会では、次回、メンバーみんなのPythonに関する意見が聞けることになっているので、それを待ちたいと思います。