Mac OS X上のPython開発環境を整えようと、Python Developers Campの前夜に思いついて四苦八苦。

まずは最新のPython 2.5（python-2.5-macosx.dmg）をPyJUGのサイト（http://www.python.jp/pub/ftp.python.org/python/2.5/）からダウンロードしてインストール。これで、/usr/local/binにPython 2.5が入る。

ただこのままだと/usr/binにあるPython 2.3が先に呼ばれてしまうため、PATHの検索順序を変更して/usr/binよりも/usr/local/binを先に検索するようにしないといけない。通常のUnixであればホームディレクトリの.cshrcなり.bashrcなりにPATHの設定を書けばいいのだが、Mac OS XでこれをやってもemacsからPythonを呼ぶと/usr/binのPython 2.3が呼ばれてしまう。

結局、ホームディレクトリに~/.MacOSX/environment.plistというファイルを作って、これにPATHを設定することで解決。

設定内容は下記の通り。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="0.9">
<dict>
    <key>PATH</key>
    <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin</string>
</dict>
</plist>

Pyhon Developers Camp 2006 夏へ参加してきたので、メモを公開。

まず1日目のセッション1つ目。

Twistedのお話

おおたにさん

Twistedって何？
　グロテスクです。
　イベント駆動型のネットワークプログラミングのフレームワーク／ライブラリ

Twistedを使っているアプリケーション
　BitTorrent
　AppleのiCal WebDAVサーバ
　Xen
　Zope3
　ほかにもいろいろある

ネットワークプログラミングのスタイル
・同期型
　ブロッキングIOを使っている
・非同期型
　ノンブロッキングIO
　select/poll
　イベント駆動

非同期型
　Connectをコールしたときに待たない
　Connectが成功したときにイベントがあがる
　ネットワークが読み書きできるとイベントがあがる

　同期型はプログラミングが簡単
　非同期型はとってもめんどくさい。とくにTwistedを使わないとめんどくさい。

めんとくさいものを使う理由
　ネットワークとCPU効率の問題
　　ネットワークプログラミングはとにかく待ちが多い
　　スレッド／プロセスのコンテキストの切り換えはコストがかかる
　同期型で効率を考えると→スレッドをたくさん作る
　非同期型だと１つのスレッドで複数の接続を処理できる

非同期でやりたい理由
　マルチスレッドの処理はスレッド間の同期がたいへん。人がやるプログラミングじゃない。

WebChat + AJAXの場合
・同期型
　AJAXで定期的にPolling
　AJAXで送信専用接続と受信専用接続
・非同期型
　AJAXで送信専用接続と受信専用接続（新たなデータがきた時点でレスポンスを返す）
　普通のWebサーバじゃできない

非同期の問題
　すべて１つのスレッドで行う
　　重い処理があるとプログラム全体がブロックする
　　重い処理はスレッドを別に作らないと効率がかえって落ちる（スレッド間の同期問題が発生してたいへん）

結論
　どちらが優れているかは一概には言えない
　どちらのプログラミングモデルを使うかは作りたいものによる
　魔法の杖は今のところない

非同期プログラミングというと
　Twisted
　標準ライブラリのasyncoreがある

標準ライブラリじゃだめなのか？
　1つの処理だけなら十分
　複数の接続＋複数のプロトコルを扱うと力不足
　asyncoreはAPIが嫌い

Twistedは？
　複数の接続、複数のプロトコルを統一的に扱える
　低レベルから高レベルまでAPIが用意されていて、好みに応じて使い分けられる
　例レベルなAPIが好き

Twistedの恐ろしいところ（すごいところ）
　ネットワークはTCP/UDP/Unix Socketなどをサポート
　ファイルアクセスも非同期で処理できる
　データベースも非同期で処理できる
　Linuxならコンソール（標準入出力）まで非同期で処理できる（でもめんどくさい、お勧めしない）
　待ちが発生しそうなことはたいてい非同期で処理できる
　select/pollを使わずにWin32のイベント処理に置き換えられる

Twistedの基本
　Reactor
　Deferred

　Factory
　Protocol
　この４つがわかっていれば、ほとんどのことはできる

Reactorとは？
　イベントループ
　イベントに応じてコールバックを実行
　スケジュール管理
　select/pollだけじゃなく、Win32, GTK1,2, QTなどのevent loopなども使用可能→クライアントのGUIプログラミングと親和性が良い
　Twistedを使ってクライアントを作る場合、WindowsだとWin32のイベントループをReactorに置き換えることで既存のコードをあまりいじらずに利用できる

Deferrdeって？
　コールバック関数、エラーバック関数を複数登録
　登録したものが順次実行される

factoryとprotocol
　Factoryは接続が確率されたときにprotocolオブジェクトを作る
　protocolオブジェクトは接続中は生存。接続が終わると破棄
　protocolオブジェクトは、ネットワークに送受信されるデータのハンドリングを行う
　protocolオブジェクト間のデータの受け渡しはfactoryを介して行う

高レベルなこと
　自分でHTTPやSMTP, IRCのプロトコルを書くのはめんどう
　Twistedのサブプロジェクトが多くのプロトコルをサポートしている（ものによってできはさまざま）
　Web関係はHTTP Protocolの上にさらに独自のフレームワークが用意されている

さらに高レベルなこと
　独自のスクリプトの仕組みがある、文法はほとんどPythonと同じ
　アプリケーションのフレームワークがある。
　UnixのデーモンやWindowsのサービスに簡単にできる

おまけ
　Twistedはサーバで使える
　クライアントでも使える
　クライアントではTwistedとpy2exeとかを使えば配布が楽

質疑応答
　止めるのはどうやるのか？
　stopというメソッド？がある

　Win32がわかっているプログラマでないときつい。特に問題が起こったときにたいへん。山のようにコールバックが帰ってきてわけがわからなくなる。どうやって解決しているのか。
　どうしているんでしょうねぇ（笑）。

Python Developers Camp 2006 夏、2つ目のセッションのメモ。

和訳プロジェクトの紹介

増田泰

和訳プロジェクトのサイト（http://www.python.jp/Zope/pythondoc_jp/）

自分は時間が取れなくなってきたので、後進にがんばってほしい。

なぜ和訳するのか
　自分のため
　　何度も英語を読み直すのはめんどう
　　コンテンツが人と情報を引き寄せる
　他人のため＝自分のため
　　頼れるリファレンスの存在はローカルコミュニティの起爆力になる
　　試行錯誤のコードが減る→信頼性が増す

和訳ドキュメントに何が必要か
　有益：お得感はユーザの向上心をあおる
　可読：より広範なユーザを獲得できる
　正確：正確な情報はソフトウェア自体の信頼性も高める
　　　　ドキュメントどおりにやってうまく動かないとソフトウェアの問題にされる
　完全：完結したドキュメントは読み手にも書き手にも安心感をもたらす
　　　　一部だけいつまでも翻訳されずに残っていると不安をもたらす
　新鮮：更新され、改良され続ける技術にこそ価値がある

Pythonの和文情報
　標準ドキュメント
　2ch：Pythonのお勉強まとめWiki
　オンラインドキュメントリンク集
　日本語PEP集

標準ドキュメント
　Pythonソース配布物についてくるドキュメント
　15000行、6Mbytes、1608ページ（CVS HEAD）

ドキュメントの形式
　書式はLaTeX
　　python.sty(pythonjp.sty)
　　ページサイズ設定、主要なマクロ定義
　　manual.cls/howto.cls(manualjp.cls/howtojp.cls)
　　構成（目次の有無など）設定
　make, python, perlを使ってビルド
　PDF, HTML, isilo, CHM対応（日本語ではisiloは出せない）
　　PS/PDF:latex(2e), Ghostscript, dvipdfm

ビルドシステム
　TeXのソース（euc）からUTF-8のPDFを作る
　同じくTeXのソースからsjisのHTMLを介してCHMを作る

和訳ドキュメント固有の特徴
　TeXソースはeuc-jp-unixで記述

和訳プロジェクト
　標準ドキュメントの和訳とメンテナンス
　成果物はPSF Licenseで公開
　PEPや3rd partyモジュールのドキュメント和訳も公開
　翻訳スタッフは随時募集

2.4を訳了したけどしんどかった。
2.5が出ているが、3000行くらい追加で訳さないといけない
現スタッフは息切れぎみ、アクティブな人が減っている
アクティブに動く人があと５人くらい欲しい

ビルドシステムのただ乗り（すでにシステムがあるのでこれをそのまま利用できる）
　mkhowto_jpを起動する
　mod_pythonのビルドMakefileを使う
　必須：Python + Perl
　和訳ドキュメントソース
　python mkhowto_jp (options) toplevel.texで作れる

ReStructuredTextの翻訳
　利点
　　ビルドしなくても読める。配布できる
　　PDFやHTMLに変換できる
　　PEPや多くのモジュールのREADMEで採用
　注意すべき事
　　推奨文字コード：euc-jp
　　タイトルやテーブルの幅：ワイドグリフ
　　マークアップの境界をASCII文字にする
　　日本語タイトル

ReSTドキュメントのビルド
　rst２html.pyを使う

私的和訳の進め方
　エディタは等幅フォントを表示できないとだめ
　辞書：おすすめはリーダースCD-ROM
　日本語力は英語力より重要
　googleで英語と日本語の和訳の候補を入れて検索して、その訳が妥当かどうかを検証する

　翻訳する底本を選ぶときは、できればバージョン管理されているものを選ぶ。リポジトリから差分がとれるので、便利。
　必ずライセンスを調べる。わからないときは著者に問い合わせる。無反応なときは暗黙の了解ができたと考える。

注意すること
　一貫性：最低、用語と文体をそろえる
　背景知識：勉強になる
　可能な限り原文を尊重する
　　私見を入れない
　　和文／英文リンクの併記

やってはだめなこと
　翻訳ソフトを使う→甘えのもと
　翻訳ソフトの訳は後でいくらいじってもまともにならない

訳し終わったら
　原文作者に連絡を取る
　MLなどに宣伝
　手放したければリポジトリを公開するのがいい

和訳にもっとも必要なもの、それは愛だ！

Python Developers Camp 2006 夏、2日目の午前中に行われたオブジェクト指向入門セッションのメモ。

Pythonでオブジェクト指向入門

森亮靖

ウォーミングアップ
　Pythonにおけるオブジェクト指向はあくまでもオプション
　オブジェクト指向を知らなくてもプログラムが書ける
　継承の概念を理解するのが重要
　classステートメントで作るオブジェクトはビルトインオブジェクトによく似ている
　Pythonのオブジェクト指向プログラミングはC++やJavaに比べると易しい
　ダイナミックな型付けのおかげで前もって変数を宣言する必要がない
　type()を使って、オブジェクトの型を調べることができる
　dir()を使うとオブジェクトの属性を調べることができる
　IDLE環境でビルトインオブジェクトをいろいろ調べると勉強になる
　IDLE環境でタイプ中にポップアップするヒントは学習にとても便利

クラスとインスタンス
　クラスとは自分で作れる型だと思えばよい
　listなどのビルトイン型は外から見ている限りクラスのように見える
　listを呼び出すとインスタンスオブジェクトができる
　listを継承してサブクラスを作ることができる
　listが便利だと思えれば、クラスの便利さも理解できる
　classステートメントが実行されるとクラスオブジェクトが作成される
　このクラスオブジェクトがビルトイン型と同じような働きをする

メソッド
　オブジェクト自身が持っている自身に対する操作
　Python的にはclassステートメントのボディーにネストされたdefステートメントで定義
　self引数を理解する、インスタンスを渡す
　1つだけの要素のタプルを使うときは(a,)のように,をつける。初心者がはまりやすい。

コンポジション
　オブジェクトのなかにオブジェクトを組み込むこと
　あるクラスのメソッドのなかで他のクラスのインスタンスを作成する
　このようなクラスをコンテナオブジェクト、メソッドをコンテナメソッドと呼ぶ

演算子のオーバーロード
　名前の前後に2つのアンダースコアがついた特殊なメソッドを使う
　このようなメソッドをフックメソッドと呼ぶ
　たくさんあるので、それぞれ調べると便利

コンストラクタ
　インスタンス作成と同時に何か処理をしたいときは、__init__という名前のメソッドを使う
　__init__をコンストラクタと呼ぶ

IS-A関係
　スーパークラスとサブクラスの関係

HAS-A関係
　コンポジション

ポリモーフィズム
　同じ名前のメソッドでもクラスによって意味が変わる

抽象クラス
　機能の一部をサブクラスに依存するクラス
　サブクラスで機能を実装しないといけない
　継承の話

デリゲーション
　委任、委譲などと訳される
　コンポジションの話
　Pythonでは__getattr__というメソッドを使う
　処理をあるオブジェクトからそのオブジェクトに組み込まれた他のオブジェクトへ委任すること

カプセル化
　カプセル化とデータの隠蔽は別の話
　カプセル化とはクラスの中にデータ／メソッドを封じ込めること
　Pythonではデータの隠蔽はできない
　クラスやインスタンスの属性はあらゆるプログラムで利用でき、値の抽出、値の変更を自由にできる
　データ隠蔽は不要という意見もある

ファクトリ
　クラスを渡すとインスタンスが返ってくるという関数
　C++などではむずかしいが、Pythonでは簡単に作れる

非結合メソッド
　<クラス名>.<メソッド名>という形で呼び出されたメソッド
　第一引数にインスタンスを指定する必要がある

結合メソッド
　<インスタンス>.<メソッド名>という形で呼び出されたメソッド
　自動的にインスタンスが渡される

新スタイルクラス
　ビルトイン型を継承したクラスは新スタイルクラス
　そうでないものはクラシッククラス
　適当なビルトイン型がないときはobjectというビルトイン型を指定すればよい
　多重継承のときのオブジェクトツリーの検索順が違う

__slots__属性
　インスタンス属性の名前を特定のものに限定することができる
　スペルミスしたときに新しい属性を作ってしまわないようにできる

Python Developers Camp 2006 夏の2日目夜に行われたライトニングトークのメモ。

Pythonメタクラスプロトコル

小田切篤

クラスもオブジェクト
クラスのクラスがメタクラス
Pythonの中ではtype関数を使って動的にクラスを作ることができる
typeはクラスなのでサブクラスを作ることができる
このとき、selfではなくclsを使う

契約による設計
　事前条件
　事後条件
　不変条件

関数デコレータ
　まにあわなかった

私には難しすぎる内容

デコレータっていいよね

田原悠西

デコレータはPython 2.4から入った機能
@の次にcallableなオブジェクトの名前を書く
基本的には単なるシンタックスシュガー
デコレータは合成関数を作るもの
デコレータは縦に並べることもできる、適用は下から
フレームワークでデコレータが提供されている場合が多い
もっと使いこなすならdescriptorを勉強すること

GRINEditの紹介

西尾泰和

Pythonワンライナーのお話、LLRingでやったやつ
JythonとはJava VM上で動くPythonの実装系
以下デモンストレーション。なかなかおもしろかった

GRINEditのWebサイト（http://www.nishiohirokazu.org/grinedit/index.html.ja）

Iron Python

石坂忠広

.Net Framework上で動くPythonの実行環境
.Net Framework上で動作する最初の本格的なスクリプト言語
Jythonを作ったJim Hugnin氏がMicrosoftで開発している
Microsoftのプロジェクトだが、オープンソース？
.Net Framework 2.0ランタイムが必要
Iron Python 1.0のインストールが必要
Python 2.4のインストールも必要
Mono 1.2版がでるという話
コンパイルなしで動くのは気持ちいい
Windowsアプリが簡単に作れる
WMIの機能を使用した管理スクリプトが書ける
COMとの相互運用も可能
x64対応が何も考えずにできる
さよならVB Script（石坂さんはMicrosoftから認められたVBのMVP）
基本的にはCPythonと同じ
ライブラリの中でC言語のライブラリを使用しているものは使えない
おいしいところは実は使えない
文字コードはUnicodeしか使えない
CodePlexからダウンロードできる（http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython）
Mixiにもコミュニティがある
www.isisaka.com/blog/石坂さんのブログ
日本語の情報はほとんどない
Windowsのexeが作れる
Visual Studioに入るかどうかは微妙、ユーザがどれくらい増えるかにかかっているかも
Monoとの互換性には問題がある。特にXML。Monoは標準にこだわるが、MSは動く事が最優先。

発表資料（http://www.isisaka.com/Portals/0/Iron%20Python%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6.pdf）

Python Developers Camp 夏、最終日朝の成果発表のメモ。

オブジェクト指向入門（森）

　各自手を動かしながら自主トレに励んだ
　初心者の質問をもとにドキュメントをまとめた

翻訳スプリント（増田）

　翻訳スプリントでは各自が選んだPEPの翻訳を行った。発表者には先着順でSpamをプレゼント！
　（以下出てくる番号はPEPの番号）
　阿部：遅刻しました。すみません。245と246をやろうとした
　　245は言語拡張の話、246はアダプテーションの話
　　内容が難しく、難航しそう。
　　ただ、ZopeやTwistedでもアダプテーションは利用されている。
　　また、GuidのPythonに静的な型を入れようとする提案にも関係するので、なんとかしたい。
　Jack：うう、早すぎてメモとれず。
　　Jackさんのやった翻訳が公開された（http://ns.jk.to/zwiki/Nikki/PEP0263）
　浦郷：357をやった。どのオブジェクトでもスライスに利用できるという話。
　小倉：関数デコレータをやろうと思ったが、英語が難しすぎたので、try exceptのPEP 341?をやった。
　小田切：333 WSGI? をやろうとしたが、量が多かったので、現状1割もいっていない。Webサーバとアプリケーションを結ぶ話。
　　一人でやるのはつらいので、皆さんの力を貸してほしい。
　竹内：339をやった。CPythonのコンパイラの情報。英語の意味はわかるけど、日本語の適当な訳語を思いつかないものがあった。
　　ドラゴンブックの日本語版を読んで訳語を見直したい。
　柴田：PEP3000シリーズ、Python 3.0で言語の中身を変更する予定なので、具体的にどこが変わるのかを書いてある。４つある。
　　３つ目までは訳してある。４つ目をやろうとしたが酔って眠ってしまったので、これからやる予定。
　増田：354、列挙データの話。200行くらい。2日でやるにはいいサイズ。

Webチャットスプリント

　石田：TurboGearsでシンプルなチャットシステムを作った。ブラウザから2秒おきにリクエストを投げている。
　安井：TurboGears、CherryPyを使った。裏でsocketを張りっぱなしにしている。
　　課題はいろいろあるが、TurboGearsである必要がないのが一番問題。
　　でも、CherryPyやMochiKitをうまく利用できるのがTurboGearsのいいところだと思う。
　田原：zope3を使った。zope3はテストドリブンなフレームワーク。朝いじったらテストが通らなくなった、でもプログラムは動いている。
　露木：DjangoとTwistedを使おうと思ったが、今回はDjangoのみで作った。AJAXでポーリングをしている。
　　Djangoのテンプレートはすごい。継承が使いやすい。管理画面がすごい。Django勉強会開催中。
　山下：Djangoを使った。昨晩Twistedをはじめてさわって、ぜひ使いたいと思った。
　　今回はまにあわなかったが、Djangoからキックして、Twistedからブラウザにデータを送るようにしたい。
　柴田：Pythonic Chatを作った。TurboGears 1.0ベータを使った。TurboGearsの管理画面もDjangoにまけていない。
　　Djangoはエンドユーザに近い人が使うフォームまで自動生成しているが、TurboGearsではwidgetを使ってごりごり作るようになっている。
　　Pythonic Cahtは関数型チャットシステム。チャット中に関数を定義できる。チャットで関数を定義し、これを実行できる。
　　定義した関数はデータベースに保存される。ただし、インターフェースの制限から関数は1行で書かないといけない。
　増田：Mimimal Django Chat、DateBased Generic Viewを使った。モデルとテンプレートを書くだけでOK。
　　さっき９時ごろから作り始めた（メモを取っている時間は11時26分！）。テーマはやっつけ！

Twistedスプリント

　おおたに：席をはずしていたのでメモとれず。
　村岡：Twistedは素人にはお勧めできない。英語力が必要。マニュアルの翻訳がほしい。
　　SQLAlchemy、O/Rマッパー、使いやすい。クライアント→Twisted→SQLAlchemy
　　Django、TurboGearsでも使うようになるので、勉強しておくとよい。

阿部さん（昨晩行うはずだったライトニングトーク）

　ZopeInterfaceとは、Pythonにインターフェースとアダプタ機能を加える為にZope 3チームが作った
　インターフェースとは定義と実装の分離
　目的は多重継承によるクラスの誤用を防ぐ
　インターフェースはインスタンス
　アダプタとは、あるクラスのインターフェースを異なる他のインターフェースへ変換するAdapterパターン
　インターフェースはアダプタを実現する為の呼び出しが可能
　インターフェースは__adapt__メソッドを実装
　コンポーネント指向の実現を目指している
　静的な型をPythonに導入する事で「実行が遅い」「実行しないとエラーが発見できない」というデメリットの解決をはかろうとしている
　def foo(x: int, y: int) -> int:のように書く
　誰も成功していない動的言語における静的な型の導入

とにかく濃い3日間でした。はい。

35人という大人数で、しかもあの濃さはなんでしょう（笑）。

オブジェクト指向入門という初心者向けセッションがあったので助かりましたが、これがなかったらついていけずにかなりつらかったかも。

和訳プロジェクトは増田さんから浦郷さんにバトンが渡されました。2.5の和訳、浦郷さんはじめスタッフの皆さん、がんばってください。

和訳には本当にお世話になっているので、よろしくお願いします。いつも感謝しております。

Djangoは熱かったですね。TurboGearsのほうは人がcoolなのかな。今回は人数的にDjangoの人が多かったよう。

帰りはJackさん、阿部さん、竹内さんと私の車で帰りました。でも運転はほとんどJackさん。

Jackさん、ありがとうございました。同乗したみなさん、うなぎはなんとかなったので、ご安心を（笑）。

主催者の柴田さん、プログラミングスタッフの皆さん、お疲れさまでした。すばらしいCampをありがとうございます。

冬にも開催予定とのことで、今から楽しみです。参加者の皆さん、冬にまたお会いしましょう。

9月14日に行われたE90オーナーズミーティングに参加してきた。

E90は知る人ぞ知るNokia Communicatorの最上位機種！　信じられないほど魅力的なスマートフォン。

欲しくてたまらないけど、日本語の問題とか電波法とかいろいろあってまだ入手していない。で、オーナーじゃないけどオーナーズミーティングに参加（笑）。

きっと濃い話が出るんだろうなぁ、と思っていたけど想像以上に濃い話の連続で大満足。

Pythonを使ったプログラミングの話も出て、Python好きとしてはとてもうれしかった。でもバージョンが2.2.2だそうで、最新のライブラリが使えず、古いバージョンに対応したものを探すのにちょっと苦労しているとか。

会場での発表内容については、

GoGo SmartphoneBLOG

に詳しく出ているので、こちらをどうぞ。18台も集まったE90の姿は圧巻！

とにかく日本でまだ発売もされていず、日本では使えないはずのスマートフォンのオーナーがこんなにいるというのは、すごいことだと思う。

Nokiaさん、お願いだから日本語版出してくれ！