PySide チュートリアル - helloworld から ユニットテストまで

ここ 2 ヶ月ほど PySide でお仕事してました。もともと PyQt で動いてたアプリケーションだったのですが、けっこう仕様変更が大きかったこともあり、どうせなので PySide で作り直してみることにしました。両フレームワークの差異はこのページにまとまっています (id:doloopwhile さんが翻訳されています)。大きくは、

  • モジュール名が PyQt から PySide に
  • PyQt の API は QString や QVariants 等 Qt が提供する型と、unicode 等 Python のデータ型の両方をサポートしていましたが、PySide では Python のデータ型のみをサポート
  • 画像等のリソースファイルをバイナリに変換したりするツール類の名称がそれぞれ変更
    • pyuic4 -> pyside-uic
    • pyrcc4 -> pyside-rcc4
    • pylupdate4 -> pyside-lupdate

PySide への変更はそんなに問題ではありませんが、まだ開発中ということもあり、pyside-rcc4 にバグがあったり、signal-slot が遅いということもあるようです。この辺りは今後に期待です。

ということで自分の復習 & メモと、PySide がちょっとでも普及すればいいなということで、PySide のチュートリアルを作ってみました。helloworld ということで、ボタンをおしたらテキストボックスに "Hello world" と表示するだけのなんの面白味もないウィジェットと、そのユニットテストを作ってみます。ソースは bitbucket に公開しました。

  1. 環境を整える
    インストールするもの
    推奨
    • virtualenv - py2exe でフリージング (実行ファイル形式に変換) する際に余計なライブラリが含まれるのを防ぐため
  2. ウィジェットを表示してみる
    Python インタプリタから以下のように打つと、ダイアログを表示することができます。 
    import sys
from PySide import QtGui
app = QtGui.QApplication(sys.argv)
dialog = QtGui.QDialog()
dialog.exec_()
  3. UI を作る
    今回作る helloworld アプリケーションはテキストボックスとボタンのみのウィジェットです。 サンプルコードの setup_ui の部分で UI を設定しています。 Qt デザイナと pyside-uic を使う方法もありますが、私は使ったことがないです。。。UI を作っていくポイントを抜粋すると、
    • 各ウィジェット (QWidget 及びサブクラス) に、レイアウト (QLayout のサブクラス) を設定する
    • 各レイアウトに子供のウィジェットを追加していく
    • ウィジェットをネストさせることで、より複雑な UI も表現できます
    UI と併せて、クラスのインターフェースも実装します。Python の property を利用してもいいですが、Qt にも QtCore.Property が用意されています。異なる点は、
    • 型を明示する
    • settar が呼び出された後に signal を送出することができる (Python の property で書いて、setattr 時に emit しちゃってもいいけど・・・)
    です。可能であれば、QtCore の Property で実装しちゃいましょう。サンプルコードでは text をプロパティ化しています。変更された際に通知する signal は text_changed として登録しています。
  4. ユニットテストを書く
    UI ができたら、ユニットテストを書きます (テストファースト :-)。Qt には QtTest というテスト用のフレームワークが用意されています。PySide では、このページにも記載されているように、Python の unittest モジュールを使ってユニットテストします。Qt はテストも signal-slot ベースです。ウィジェットにある signal が創出され、slot が処理した後に、ウィジェットがどうなっているか。QTest にいくつかの基本的なイベントを発生させるメソッドが用意されています。サンプルコードではボタンをクリックした際のテキストボックスの状態をテストしています。まだ signal-slot を実装していないので、テストは失敗するはず。
  5. イベント (signal-slot) を実装する
    ユニットテストを通過できるように signal-slot を実装していきます。signal-slot の書き方は何種類かあります。サンプルコードの setup_events の箇所でイベントをセットアップしています。ここに connect をたくさん書いてもいいですが、子ウィジェットのイベントを再帰的にコネクトする connectSlotsByName を指定するのが好きです。コード量が少なくなるのでこの書き方を多用しています (イベントハンドラの追加をするたびに connect とか書きたくない)。
    connectSlotsByName を利用すると、slot メソッドを def on_<object name>_<signal name>(<signal parameters>) という風に書けるようになります。 この object name は、各子ウィジェットに対し setObjectname で指定してあげる必要があります。サンプルコードでは、base_layout, lineedit, button すべてにセットしていますが、今回の要件を満たすには button ウィジェットだけセットすればいいです。これでサンプルコードのように on_button_clicked で button の clicked イベントの slot を作成できます。

以上、なんの面白くもないチュートリアルですが、 PySide での開発の流れが少しでも見えたら良いかなーと。

コメント

コメントを投稿

このブログの人気の投稿

Python から Win32 API 経由で印刷する

Win32 API から印刷をするためには、プリンタデバイスコンテキスト (Printer DC) を利用します。具体的には以下のような順序で印刷します。 プリンタドライバからハンドルを取得する プリンタドライバのステータス API から印刷可能か同かを取得する プリンタデバイスコンテキストを作成する ドキュメントを開始する 必要であればフォント等を設定し、印字、改ページ処理などをする ドキュメントを終了する (この時点でプリンタスプールサービスに登録されるようです) プリンタデバイスコンテキストを開放する プリンタドライバのステータス API を監視し、印刷が正常に終了したかを取得する プリンタドライバのハンドルを解放する 太字の手順 (3 - 7) は Win32 API で共通ですが、それ以外の手順 (1, 2, 8, 9) はプリンタドライバに依存しているため、Python から制御したい場合はライブラリを作成する必要があります。これについては、ドライバマニュアルとにらめっこしながら ctypes.windll でがんばります・・・。プリンタ接続、用紙切れ、ミスフィード等のプリントエラーを制御する必要がなければ、書く必要はありません (排他制御が必要なプリンタを除く)。プリンタドライバ毎に変わる部分は置いといて、太字の Win32 API の部分の覚書です。 プリンタデバイスコンテキストを作成する import win32ui import win32con PRINTER_NAME = '[コンパネ -> プリンタとFAX -> に登録しているプリンター名]' PIXELS_PER_INCH = 1440 # 1 インチ毎のピクセル数 INCH_PER_POINT = 72 # 1 インチ毎のポイント数 SCALE_FACTOR = int(PIXELS_PER_INCH / INCH_PER_POINT) #　わざわざ計算せず 20 と指定する場合が多い dc = win32ui.CreateDC() dc.CreatePrinterDC(PRINTER_NAME) # 指定したプリンタ名のプリンタデバイスコンテキストを作成する self.dc.SetMapMode(win32con.MM
続きを読む

Disqus のスケール - Django 編

イメージ
やり直し。2010 年の Django Con のスライド より。 Disqus は多くのサイトに組み込まれているサービスのため、メンテナンスによる停止が難しい。 >>> サーバの構成 エッジロードバランサーに HAProxy: heartbeat 構成。レポートが素敵。 HTTP ゲートウェイキャッシュに Varnish Django サーバとして Apache + mod_wsgi: 30 台ぐらい。メモリリークを防ぐために maximum-requests をセット。Ganglia で監視 キャッシュに memcached: 25 台ぐらい PostgreSQL ロードバランサーに HAProxy/ PgBouncer : コネクションプール用。 PostgreSQL: 10 台ぐらい。 Slony-I で非同期レプリケーションとフェイルオーバー。 ログは syslog-ng: pgFouine でスロークエリーをロギング。 全部でサーバ 100 台ぐらい。他にユーティリティサーバ 15 台、後は HAProxy と heartbeat 用に 20 台ぐらいの構成。Varnish と syslog-ng を除けば Django のデプロイ手順に掲載されているような教科書通り (良い意味です) の構成です。(なんで Apache なの？nginx + gunicorn 速いよって突っ込まれてますね >>> データベースのパーティショニング Django はアプリケーションレベルで簡単に 垂直 パーティショニングができます。アプリケーションごとに DB 分けたり、DB をアプリケーションレベルでルーティングできます ( ドキュメント )。 水平パーティショニング (a.k.a シャーディング) もアプリケーションで 書ける (なるほど・・・)。 >>> キャッシュの削除 Django は QuerySet の結果をキャッシュするけど、それがかなりメモリを消費する。なので SkinnyQuerySet を作った (たぶん Johnny Cache の方が有名？
続きを読む

Disqus のスケール - Django で月間80億PVを処理する

私が把握してる限り Django で一番大きなサービス Disqus のスケール (執筆時点ではサービスダウンしてる)。元ネタは Scaling Django to 8 Billion Page Views です。 月間80億PV 、 45k req/s のほぼすべてのトラフィックを Django で処理しているとのこと。抄訳になるかな。 WAF は 高速開発とパフォーマンス 、 新しい人が入ってすぐに開発に参加できることとカスタマイズ 等のトレードオフがあります。この記事ではそのトレードオフである高速開発とパフォーマンスをどう両立させるか、Disqus のノウハウが紹介されています。 >>> なぜ WAF (Web Application Framework) は遅いのか 最初に思い浮かぶのは、アプリケーションに必要ではないボイラープレート ( django.contrib とか?) や不要なコードがあるため。そもそも Django の思想が Python 同様 " バッテリー同梱 (batteries included) " のため、Django は他の Python 製 WAF よりボイラープレートが多いです。Disqus 曰く "実は 言語や WAF は遅さにあまり関係ない " それより " ネットワーク内の他のサービスとの通信 " のオーバーヘッドが原因とのこと。これは一般的によく言われてることですし、大規模になればなるほどそう。Disqus の場合は PostgreSQL, redis, Cassandra , Memcached 等のサービスが使われているそうです。DB へのスロークエリーやネットワークのレイテンシーは Django のようなボイラープレートによるオーバーヘッドを軽く上回ります。この待ち時間を回避する一番メジャーな方法はキャッシュの使用です。Django では キャッシュフレームワーク を使用します。Django でキャッシュを使うのは簡単ですし、バックエンドに Memcached を使うと充分高速化できます。 はい。ここまでは一般的な話です。こっから。 >>> 45k req/seq を処理する キャッシュしたところで
続きを読む