第2回Python勉強会（Django）

Python Django

前回に引き続き、2回目の勉強会が開催されました。
今回はDjangoを使ってWikiを作るのが課題でした。
資料は『http://www.everes.net/2007/may/07/django-wiki-after-ordering-pizza/』を参考にして作ったそうです。
作り方自体は動画を見てもらえればわかるので、印象に残ったことを書いていきます。


前回の補足

パッケージの作り方

Pythonに認識されたいディレクトリに__init__.pyというファイルを置く。

lambda

クロージャのこと。以下のように書くことができる。

a = lambda x:x*2
print a(2)

Djangoを使う

Djangoは Python で書かれたオープンソースのWebフレームワークです。
ギタリストのジャンゴ・ラインハルトが名前の由来だそうです。かっこいいですね。
Railsは若干触ったことがある程度ですが、簡単に比較して見ます。

DjangoのRailsと似ているところ
  • コマンドでmodelなどを生成･･･View（Railsのコントローラにあたる）も一緒に生成されていますが。
  • 開発用サーバが一緒にある
  • ORマッピングしてくれる
  • Scaffoldのようなものがある･･･DjangoのAdminですが、Scaffoldより高性能できれいです。
DjangoのRailsと違っているところ
  • プロジェクト生成時のファイル数が少ない ･･･ 設定のためのファイルやコマンドライン用のファイルしかありません。
  • URLマッピングを書く必要がある･･･Railsのデフォルトだと、コントローラ名やメソッド名がURLに使われるのですが、Djangoでは正規表現を使ってマッピングします。
  • 設定ファイルが多い？･･･上もそうですが、モデルを有効にするにも設定を書く必要があります。
  • modelにIDがいらない･･･勝手につけてくれます。
  • MVCではない ･･･ 設計思想はMVCでと同じですが、モデル (Model)、テンプレート (Template)、ビュー (View)のMTVです。
  • mkdirの回数が多い ･･･ コマンドを使う機会が少ないのが理由。
  • T(V)とV(C)の対応 ･･･ 少し覚えるのが面倒かも。
  • 国際化が楽 ･･･設定ファイルを書き換えるだけでAdminが日本語になります。

まあ挙げていけばきりがないのですが、主に感じたのはこのくらいです。


違和感を覚えたところ

スコープがJavaと違う

Javaの例外処理のtry catchのようにPythonにはtry exceptがありますが、tryの中で使い始めた変数をそのままtryブロックの外でも使えます。
forでもいけるようです。

名前空間が適当？

Javaだとパッケージ名にURLを使うことが推奨されていますが、Djangoの場合だとdjango.〜と続くように、結構適当なような気がします。
衝突とかしたときどうするんだろう。


よかったところ

Docutils

ドキュメントを変換するライブラリですが、非常に便利です。
今回は、Wiki記法を実装するために利用したのですが、LaTeX2eなどいろいろと出力できるようです。
Javaにはこういうライブラリはないので魅力的です。

タプル

最後にカンマ（,）をつけるのがナニでアレかと思っていたのですが、設定ファイルを書いたりするときには非常に便利です。
コメントアウトをしたり、削除したりしたときによくカンマ最後につけ忘れたりつけたままだったりしてエラーになったりするので、こういう風になっているとそういう問題がなくなりますね。



とまあ今回はこのような感じでした。
少し癖があるフレームワークですが、早く軽くWebアプリケーションが書けそうです。特に、今回はDB周りをほとんど意識せずに作業ができたので、快適にプログラミングができました。
まだなじめないところもあるので、慣れるために何か一つアプリを作ってみようかと思っています。



担当者が卒研が忙しいので今回を最終回にするといっていましたが、たぶんまた来週もやってくれるはずと期待しています。