aodag's posthaven

pytest, mock, testfixture!

2013-03-17T15:57:00Z

(´・ω・`)はい。こんにちは。パーフェクトPythonも無事？発売されて一安心なaodagです。まあ、なんかテスト関連でよくいろいろ言ってる気がするのですが、最近ツールを変えたので、覚書を。これまで：

nose
unittest2
mock

という組み合わせでした。 unittest2の豊富なassert系メソッドとnoseの豊富なプラグインってところです。テストケース自体はunittest2で書いて、noseのテストランナーを使うと。が、最近もうこの２つはpytestに変えました。だいたいいつも使ってるようなのは、pytestでまかなえるし、pytest-covがあれば十分かな。追加で使うツールとして、mockは続投、testfixtureが便利な気がするので、使い始めてます。それぞれのツールの使い方はだいたいそこらへんのマニュアルとか見てくれればいいと思うので、pytestでどのようなことをしてるかってのを。 zopeやpyramid界隈では、テスト用のダミーやフィクスチャ（データフィクスチャじゃないよ。まったく某フレームワークのせいでフィクスチャっていうとデータのことばかり...）を testing というモジュールにまとめておくのが慣例です。で、pyramidにもtestingモジュールがあり、 testing.setUp, testing.tearDownというのが、テスト用のコンポーネントレジストリを初期化するフィクスチャです。 pytest的なフィクスチャにしてみます。

@pytest.fixture

def config(request):

    from pyramid import testing
    config = testing.setUp()

    def fin():
        testing.tearDown()

    request.addfinalizer(fin)

    return config

pytest.fixtureデコレータでフィクスチャの登録をします。なかでやってるのは、testing.setUpの呼び出しと、testing.tearDownをテスト後に呼び出すための設定です。 requestがそういうフックを設定するためのオブジェクトです。このフィクスチャを使うには、テストケースの引数にconfigという名前をつけます。 pytestが、フィクスチャの名前と同じ引数のところに自動でフィクスチャの戻り値を渡してくれます。

from .testing import config

def test_it(config):

    config.include('test.under.the.module')

楽ですね。 testfixtureは、汎用的なフィクスチャがそろっています。日付やログ、ファイル出力、ファイルシステムの操作など、ユニットテストでよくあるめんどうな部分をカバーしてくれてるので、便利に使えるようになりたいものです。テストツールのセットアップテストツールが増えてくるとそれをインストールするのも簡単にすませたいところです。テストツールようのrequirementsを用意しといてもいいのですが、 setup.pyに書く場所があるので、そっちを使います。

setup(name="...",
      ....
      tests_require=["pytest", "mock", "testfixtures"],
      ....
     )

このように書いておくと、 python setup.py test とすれば、現在のディレクトリにインストールされます。うざいですね。 extras_requireを使うと、現在の環境にインストールできます。

tests_require = ["pytest", "mock", "testfixtures"]

setup(name="test.under.the.package",
      ....
      tests_require=tests_require,
      extras_require={"testing": tests_require},
      ....
      )

このようにしておくと、 python setup.py develop easy_install test.under.the.package[testing] などのコマンドでテストツールまで、インストールできます。

長くてめんどうなので、 setup.cfg にエイリアスを作ります。

[aliases]
dev = develop easy_install test.under.the.package[testing]

最近のpip (1.2以上のバージョン)も extrasをサポートしています。

pip を使う場合は pip install -e .[testing] というコマンドで、ほぼ同じようになります。

これらのツールはpython3対応もしてるので、長い付き合いができそうです。

新年的なアレ

2013-01-02T06:51:03Z

From Evernote:

新年的なアレ

coffescript,dart,typescriptのどれか１つを勉強する
自炊がんばる
ポモドーロとかGTDとか、なんかそんなので改善なやつをする
(´・ω・｀)ブログは３０エントリ目指す

New Year's Python Meme 2012 #2012pythonmeme

2012-12-31T11:24:19Z

From Evernote:

New Year's Python Meme 2012 #2012pythonmeme

New Year's Python Meme 2012

去年 http://aodag.posterous.com/new-years-python-meme-2012pythonmeme

1. What’s the coolest Python application, framework or library you have discovered in 2012 ?

obviel, that is zopish javascript framework.

2. What new programming technique did you learn in 2012 ?

ZCA
Client Side MVC

3. Which open source project did you contribute to the most in 2012 ? What did you do ?

pyramid, repoze. Mainly, i've committed to support python3.

4. Which Python blog or website did you read the most in 2012 ?

reddit, stackoverflow

5. What are the three top things you want to learn in 2013 ?

async programming: gevent, tornado, zeromq

HTML5 and Mobile Web

6. What is the top software, application or library you wish someone would write in 2013 ?

pip with new generation packaging

acceptance testing tool with sphinx documentation
issue tracker that replaces Trac and Redmine.

2012の新年のあれがどうなったか

2012-12-31T10:39:00Z

Pylons/Pyramid勉強会を4回開く

PyConJP の併設イベントを入れて4回開催した！達成！

Pyramidベースのフレームワークを作る

(´・ω・`)なう、検討中。

Web関連ライブラリのPy3対応にコミットする

PyramidとかRepozeに貢献できたと思うので達成！

海外のPyConその他のカンファレンスに1回は行く

EuroPython行ったので達成！

英語力強化（アウトプット方面）

(´・ω・`)がんばってる。

ブログを50エントリ書く

(´・ω・`)50どころか2桁いってない事実..

(´・ω・`)と、いうことで、3/6達成でした。

英語とか

PySPAアドベントカレンダー

2012-12-25T11:12:22Z

From Evernote:

PySPAアドベントカレンダー

はい。皆勤賞にして、すべてのいただきますを唱和したaodagです。

公式には全10回、4食ずつで40回の「いただきます」「ごちそうさまでした」をしてきたことになりますが、

(´・ω・｀)どうでもいいですね。

「いただきます」の動画が残ってました。

(´・ω・｀)はい、ほほえましいですね。

半年に1回ペースで10回あったということは、5年以上たったわけですね。

その間の僕のPythonへの関わりはどのように変わったか考えてみました。

興味の対象

TurboGears,WSGI,Pylons,Repoze,buildout,pyramidなどなど

ひたすら強力なものを追い求めた結果ですが、まあ、僕が選ぶものがどれだけ流行らないのかという歴史です。

というわけでなんか振り返りとしてもぐだぐだなので、この辺で。

IT業界Heavy Metal Advent Calendar 2012 22日目

2012-12-22T10:33:00Z

http://www.adventar.org/calendars/50 こちらからのアドベントカレンダー。

眠気を吹き飛ばすメタルを紹介ということらしいので

SavatageのJesus Saveです。

アルバムがロックオペラってことで全体通して聞いてると眠気が襲ってくることになりますが:D

次は速弾き野郎Impellitteli の kindom of light

その前のアルバムでブレそうだったこともあり、このアルバムでは吹っ切れたようにひたすら速弾き。

コーディングのお供に最適です。

で、ロブ・ロックのボーカルが地味にはまってきたりもするわけで。

という2枚を紹介しときます。

（あ、両方Chrisだ。

2012 Pythonアドベントカレンダー 18日目 PasteDeployを知ってるかい？

2012-12-18T05:06:00Z

From Evernote:

2012 Pythonアドベントカレンダー 18日目 PasteDeployを知ってるかい？

PasteDeployを知ってるかい？

さて、2012 Pythonアドベントカレンダーの18日目です。

一応Webフレームワークに関連してればよいということで、普段あまり言及されないPasteDeployの話をしておきます。

PasteDeployとは？

ああ、プロジェクトのテンプレートを展開するやつですよね？とかしたり顔で聞いてくる奴は自分で穴掘ってもぐっといてください。

PasteScriptのpaster createのことではありません。

paster serveのほうです。

PasteDeployは、iniファイルでWSGIアプリケーションやミドルウェア、サーバーの設定や構成を管理するものです。

で、そのiniファイルを paster serveに渡せば WSGIアプリケーションが実行されるわけですね。

WSGIがわからない人は、 http://shomah4a.bitbucket.org/advent_calendar/2012/wsgi.html を読んでね。

ちょっとだけWebOb

まあ、とりあえずHelloなWSGIアプリケーションでも作って動かしてみましょう。

helloapp.py

from webob.dec import wsgify

@wsgify

def hello(request):

return u"Hello, world!"

shomah4a の例と違うのはWebOb使ってるところ。

ではこれを動かすので、 webob と pastescriptをインストールしましょう。

$ pip install webob pastescript

pasterコマンドが使えるようになりますが、これでいきなりWSGIアプリケーションを動かせるわけではありません。

WSGIアプリ、ミドルウェア、サーバーの構成を定義する ini ファイルが必要です。

PasteDeployしてみよう

ひとまず最少の構成では、WSGIアプリとサーバーを指定すればOKです。

hello.ini

[app:main]

paste.app_factory = helloapp:main

[server:main]

use = egg:paste#http

host = 0.0.0.0

port = 5000

さて、今あるのは単に helloというアプリケーションだけです。

pastedeployでは、直接アプリケーションを参照するのではなく、アプリケーションを返す関数（ファクトリ）を指定するようになっています。

helloapp.py

def main(global_conf, **app_conf):

return hello

今のところ特に設定を必要としてないので、さっきの hello をそのまま返すようにします。

$ paster serve hello.ini

で動きますね。

設定を使う

実際のところWebアプリケーションだと、データベースへの接続だとかそういった設定が必要です。

が、ここでSQLAlchemyの話を出すと説明しきれないので、messsageとか渡すことにしましょう。

設定をもとにアプリケーション作成するので、クラスにします。

class HelloApp(object):

def __init__(self, message):

self.message = message

@wsgify

def __call__(self, request):

return self.message

def main(global_conf, message, **app_conf):

return HelloApp(message)

で、 hello.ini は以下のように変更します

[app:main]

paste.app_factory = helloapp:main

message = Hello, world!

(´・ω・｀)さて、ここからが本編です。

ええ、ここまでは、PasteDeploy自体知らないなんていう人が多いのではないかということで書きました。

なんせ、このアドベントカレンダーは8割がたDjangoネタですからね。おまいらフレームワーク1つしか知らないのか。

PasteDeployの設定を共有する

とりあえず設定値を２つにしてみます。

helloapp.py

class HelloApp(object):

def __init__(self, message1, message2):

self.message1 = message1

self.message2 = message2

@wsgify

def __call__(self, request):

return u"{0} {1}".format(self.message1, self.message2)

def main(global_conf, message1, message2, **app_conf):

return HelloApp(message1, message2)

hello.ini

[app:main]

paste.app_factory = helloapp:main

message1 = Hello

message2 = world!

まあこんなもんです

が、たまにmessage1だけを変えたい時があるかもしれません。

そんなときには

セクションを追加します。

[app:hello]

use = main

message1 = Hi

このように use でセクションを指定して、変えたいところだけ設定します。

このappを実行するには、 paster serve に -n オプションで hello と指定します。

$ paster serve hello.ini -n hello

という、pastedeployで設定の共有や上書きができるよ。というお話でした。

これで、 production.iniやdevelopment.iniなどで、設定を共有しながら、デバッグフラグやDB接続など、必要な部分だけを変更して扱うことができますね。

19日目は @podhmo お願いします。

virtualenvなしでもプロジェクトごとのライブラリを管理する方法 #python

2012-05-03T17:47:00Z

ついうっかりvirtualenvせずに setup.py develop してしまったわけですが。

しかもwindowsだったので、権限でのストップがかからずそのまま大元のsite-packagesにざっくりインストールされました。

さて、setup.py developの場合、pipとは違い、eggごとのディレクトリにインストールされます。

で、これだけじゃPYTHONPATHに入ってこないわけで、site-packages内の *.pth ファイルにパスが羅列されているというのが、結構前に調べた結果。

インストールされてしまった、eggたちも、全部削除するんでなく、easy-install.pthの記述を消してしまえば、問題ないわけです。

さて、このeggたちを有効活用できないものか。

というか、そうするためにeggはディレクトリが分けられていまして、 pkg_resources.require() を使って、sys.pathに追加できます。

ポイントは、 pkg_resources.requireを使うと、そのeggが依存するeggもsys.pathに追加されるということ。

なので、今開発しているパッケージが bucho という名前で、きちんとsetup.pyに依存ライブラリを指定してあるなら、 pkg_resource.require('bucho') と書けば一発で必要なライブラリがsys.pathに追加されます。

さて、ちょっと目先を変えて、setup.pyから実行できるサブコマンドはサードパーティライブラリからも追加できます。

有名どころでは、noseのnosetestsコマンド、sphinxのbuild_sphinxコマンド。

で、先ほどの pkg_resources.requireですが、setup.pyから起動されるサブコマンドでは、setupされてるeggを内部でrequireしてあるようで、コマンド自体のライブラリ(たとえばnose)があらかじめimport可能な状態なら、問題なく setup.py nosetestなどできます。

さらに、pkg_resources.requireはバージョン指定も可能です。また、easy_installコマンドは-m （マルチバージョン）オプションがあり、このオプションをつけると easy_install.pthに追記されずにインストールされます。このあたりの仕組みを使いこなせば、どんどん増えていくvirtualenvに悩まされることはなかったでしょう。

という、もうすぐpackaging/distutils2が出てしまう段階で、こんなTIPを調べたことに腹正しさを感じつつvirtualenvしなおしています...

BPStudy #54で発表してきたよ！

2012-02-28T03:17:00Z

ということで第二部で、Python3移行の話をしました。

組織的な移行じゃなくて、オープンソースコミュニティでのライブラリ対応の話です。

http://www.slideshare.net/aodag/bpstudy54-python3

なんか誤解されちゃってる気がするので、補足しとく。

Python3自体は別に難しくないし面倒でもないです。

スライド中の苦しい話は、2と3と両方で動くように書くので面倒なんです。

そういうの気にしなければ、Python3使うのなんて簡単なんだからね！

Python2.4から3.2までで通用するexcept句の書き方

2012-02-21T15:39:00Z

まあ3系文法との互換性って2.6からの話なんで、2.5とかの非互換は結構あきらめていたのですが。

PasteDeployは2to3なしで、2.5から3.2をサポートしてるのですね。

except句って、2.5だと

except Exception, e:

という書き方で、2.6以降で導入された

except Exception as e:

じゃないと3で通用しないわけです。

PasteDeployが、これをどう解決してるかというと、

except Exception:
    e = sys.exc_info()[1]

な、なるほど。これなら確かにどちらのバージョンでも通用する！

が、こんな書き方するよりは、2.5を切り捨ててしまいたい。

http://www.voidspace.org.uk/python/articles/porting-mock-to-python-3.shtml

ちなみに2/24のBPStudy #54 で、こんな感じの話をしますのよ。

http://connpass.com/event/268/

まだ枠あいてるっぽいです。どうぞよろしく。

pyramid_formalchemyでpyramidにもadminアプリを！

2012-01-19T15:08:00Z

まあ、django中毒なみなさまにはadminがないフレームワークなんて信じられないだろう。

悪いけど、admin作れるのはdjangoのO/Rマッパーがアホなせいも多分に影響してるんだよね。

とはいえ、djangoのadminに慣らされた身としてはadminないとか耐え難いことかもしれない。

ということで、pyramidですぐに使える（でも、完璧じゃない）adminツールを紹介することにするよ。

まあ、pyramidのプロジェクト作るぐらいのことは、日ごろ「pyramidはflaskと違いはない」なんて言う人たちには朝飯前だよね。

そうじゃない人たちのために、復習しておこう。

virtualenv --distribute padmin

virtualenv使うのは、もはや常識の範疇。最新のvirtualenv1.7はno-site-packagesがデフォルトだ。

アップデートしてない君は以下のようにする必要があるだろう。

virtualenv --no-site-packages --distribute padmin

そしたらpadmin以下で、pyramidをインストールしよう。

cd padmin

bin/pip install pyramid

windowsユーザーの皆様へ。

僕はこのエントリをwindowsで書いている。macの中途半端なunix環境は許しがたい。

この bin/pip のコマンドを含めて、windowsのvirtualenv環境はscripts以下にコマンドがあるってことを前提にして欲しい。

bin/pip って書いてある場合は、windowsだと、 scripts/pip って書いてあると脳内変換して読み進んでいただきたい。

ではプロジェクトを作ろう。

pcreate -t alchemy padmin

これでとりあえずsqlalchemyを使うpyramidアプリケーションの雛形ができる。

pyramidに習熟した人たちだったら、ここからnoseやwebtestなどをインストールするだろうが、まあ、それはおいおい追加していただくとして。

ここからが、ちょっと違うところだ。

さらにpyramid_formalchemyをインストールするんだ。

../bin/pip install pyramid_formalchemy pyraid_fanstatic fa.jquery

なんか説明してないものもインストールしてるね。

fanstaticというのはjavascriptを管理するためのライブラリだ。

最近のWebアプリケーションはjavascriptなしでは成り立たないと言ってもいい。

formalchemyはfa.jqueryという追加のモジュールがあって、これを追加すると、javascriptを使ったリッチなUIが使えるんだ。

fanstaticはそのjavascriptを管理するためにfanstaticを使っている。

pyramid_fanstaticは、fastaticをpyramidにより親和性のあるように統合できるアドオンだ。

これらがインストールできたら、formlalchemyを使うためのpcreateを実行する。

pcreate -t pyramid_fa padmin

これでできあがるのは

padmin/padmin/fainit.py

padmin/padmin/faform.py

padmin/padmin/faroute.py

だ。

padmin/__init__.pyのなかで

config.include('.fainit')

とすれば、もうformalchemyを使ったadminは設定完了だ。

とはいえ、１つ修正する点がある。

pyramid_formalchemyのadminで管理できるのはコンストラクタがなにも引数をとらないmodelだけだ。

そして、alchemyスキャッフォールドを展開した直後のmodelsには、引数を受け取るコンストラクタが定義されている。

ここは修正が必要だ。

そもそもsqlalchemy.ext.delcarativeから定義したモデルはコンストラクタが自動生成される。

ここは __init__ メソッドを潔く削除しよう。

実行前にデータベースを作成しておく。

pyramidのalchemyスキャッフォールドはデータベース作成と初期データ生成のコマンドまで実装してくれている。

このプロジェクトをpip install -e としてあげれば、このコマンドを使えるようになる。

pip install -e padmin

として、プロジェクトをvirtualenvに登録しよう。

登録できたら、popurate_padmin というようなコマンドを実行してあげればいい。

virtualenviに入ってるコマンドということを、お忘れなく。

bin/popuate_padmin padmin/development.ini

これでデータベースもできた。

あとは実行するだけだ。

bin/pserve padmin/development.ini

http://localhost:6543/admin にアクセスすれば、adminアプリケーションを使うことができるはずだ。

だが、カスタマイズなどを考えると、まだ実用に遠く及ばない。

formalchemyを使うか、deform+coalnderを使うかは、今のところ用途に応じて。ということになる。

過去記事をまとめた

2012-01-15T18:13:00Z

http://delicious.com/stacks/aodag

5エントリないとStackとして公開できないらしく、あと3カテゴリほど非公開な状態。そのうちなんとかする。

Pyramidを拡張する作法知識編

2012-01-14T15:45:00Z

(´　　＞　ω　＜　)拡張しちゃうよ！

アドオン作るために必要なこと。

pyramidのアドオンは、config.includeメソッドで取り込まれます。

そのとき、アドオンのincludeme関数が呼び出されます。ここがアドオンの入り口です。

config.include('hoge')

hoge.py

def includeme(config):

ここでアドオンの処理をする

アドオンがなにをするかはなにも決まってません。なにもしなくてもincludeできればアドオンです。

引数でconfigが渡されるので、定型的な設定（認証やセッションなどの設定）をすることもあれば、viewやmodelまでそろえたアプリケーションを追加することまで可能です。

拡張とは？

directive

pyramidでは、configのメソッド(directiveと呼びます)を通じてアプリケーションの構成を定義していきますが、directiveを追加できます。

設定内容を追加する

directiveでは最終的にconfigが持っているコンポーネントレジストリ(registry)に設定内容を登録していきます。

registryへの登録内容も、アドオンで追加可能です。

これにより、アドオンを書く場合にありがちなモジュールグローバルなオブジェクトを回避できます。

venusianデコレータ

directiveはconfigがないと呼べないので、configを持ちまわるのがかったるいですね。

デコレータで設定してしまうのがイマドキです。

が、デコレータはimportするだけで効果を発揮するため、import順を気にしたり、ユニットテストのときまで動いてしまったりと副作用が大きすぎます。

pyramidではvenusianデコレータを全般で利用して、config.scanでトリガーを引くまでデコレータの副作用を発生させないようになっています。

view_configデコレータが一番多く利用されますが、これらは内部でconfig.add_viewを呼び出すフックを設定するだけです。

scanしたときに初めてadd_viewが実行されるようになっています。

と、いうのが拡張するときに知っておくべきことです。

新年のアレ

2012-01-03T10:33:00Z

目標

Pylons/Pyramid勉強会を4回開く
Pyramidベースのフレームワークを作る
Web関連ライブラリのPy3対応にコミットする
海外のPyConその他のカンファレンスに1回は行く
英語力強化（アウトプット方面）
ブログを50エントリ書く

In defense of zope libraries 翻訳その３

2012-01-01T15:07:00Z

セカンドシステム症候群の三重苦や継続的なサポートのなさ、ブランドは傷つき、"Zope"の名を過去のものにした。

PythonコミュニティでもZopeに関連したものを使ったことがない人々に、過剰なエンジニアリングや技術者の自己満足ととらえられるようになってしまった。

オリジナルのZopeアプリケーションサーバーであるZope2の評判は、未だモノリシックでお粗末な設計に苦しんでいること以外は文句の付けようがなかった。

ブランドは許容を超えてしまった。

そしてZopeの言葉がつくものはほんの少しの尊敬と、悪いイメージを持ち始めた。

かろうじて、この評判はweb開発に関係している部分だけだった。（？PythonはWebだけではないので、それ以外の業界ではそういうイメージを持たれなかったということか？）

ブランドの崩壊はあったが、それでもPhiladelphiaの開発者は、Zopeの再構築は技術的に成功したと考えていた。

ZopeのオブジェクトデータベースであるZODBはZopeから切り離され、独立に利用できるようになった。

コンポーネントアーキテクチャは複雑な入力に対して、非常に迅速な処理を行うのに有用なことを証明した。

Zope3のインターフェイスシステムは、インスタンスベースのダックタイピングを構造化できた。そして、これはAPIドキュメントを書きやすくした。

Philadelphaの開発者にとってのZopの存在意義は、宣言的なコンテキスト依存のセキュリティシステムだった。

これは完全に混乱していた。これらは再利用はできないが、アイディアは再利用すべきであった。

オブジェクトグラフ上を"traversal"してセキュリティコンテキストを決定するというZopeのコンセプトはZope2やPlone界隈では常識であった。

そして、そのころ、それに変わるものは競合のシステムは持っていなかった。

そして、もうみんな気づいているだろう。Philadelphiaの開発者は私のことだ。そして、これらはすべて私の経験してきたことだ。

この経験を振り返ることが楽しいことだとはいえない。Zopeがこのような結果になってしまったのは、私も大きく傷ついた。

これらの経験は、私にいくつかのことを気づかせた。

多くの開発者はとてもとてもリスクを嫌う。彼らは小さなステップを好む。またはまったく変化したくない。彼らに技術的な関心のないことを認めないといけないし、彼らが好まない方法を使わないのも認めなければならない。

他の開発テクニックや技術と一緒に使えないような、完全に統合されたモノリシックなシステムの魅力は、徐々に消えていく。そして、魅力が消えていくと、忌むべきものに変わるのだ。

モノリシックシステムによるこうした問題に対する自然な反応は、すべてを完全にプラッガブルにすることだ。だが、これは罠だ。

テストは非常に重要だ。ドキュメントはもっと重要だ。

複雑なシステムを入れ替えるなら、もっとシンプルにしていかなければならない。複雑さを追加してはいけない。

ブランドは重要だ。○○とはなにか？という質問には１つの答えだけを持つべきだ。Subletyとブランディングを混ぜてはいけない。混乱をもたらすだけだ。

PyramidはZopeの影響を大きく受けている。それはとても広範囲に及ぶ。派生物だ。Zopeがなければ、Pyramidはなかったとはっきり言える。

だが、同時にPyramidはZopeへの回答だ。

Pyramdiを作ったのは、Zopeの良さと偉大さを理解しているからだ。

その一方で、zopeの名前を持つパッケージをいくつか使っている。これらはZopeと関係なく十分再利用できるようになっているからだ。

PyramidはPylonsやDjangoからも大きく影響を受けている。だが、皮肉なことに、これらのシステムはそれほど良く作られていなかったため、簡単に再利用できるものはなかった。

Pyramidはzope.interfaceを以下のことに利用している。

宣言的なコンテキスト依存セキュリティ機能のためにコンテキストを発見する（ACL認証機構）

コンテキストベースでのビューを発見する機構。（たとえば例外ビュー）

Pyramidはzope.deprecationを、フレームワーク利用者にAPI廃止を通知するために使っている。

これは、まったく依存関係をもたず、１００行ほどのコードしかない。Zopeアプリケーションサーバーとはまったく関係のないものだ。

Pyramidを使う分には、これらのことはまったく気にする必要はない。

フレームワークの開発者はこれらのことを知っている必要があるだろう。

これらをフォークして名前を変える方法もあったし、Zope懐疑論者に知られないようにしても良かった。まったく違う名前でリリースしなおしてしまえば、もっと評判が良かったかもしれない！

だが、zopeが悪だと単純な二元論を持つ人たちのために名前を変えるだけのためにフォークするのは、何百人という貢献者のたちへの冒涜だ。

彼らはZopeブランドの悲劇にかかわらず、賞賛と尊敬に値する人たちだ。

彼らは私がしてきたよりも（そして将来にわたってもきっと）PythonのWeb開発に多くの貢献をしてきている。きっとこれを読んでいる読者たちよりも。

zopeは悪、pyramidはzope、だからpyramidは悪だという議論をしている人たちには、もっと勇敢になってもらいたい。

Within your first ten minutes of evaluation, considering the stuff I've written above, please try to momentarily entertain the notion that the history of Pyramid's Zope dependencies isn't written entirely by hapless dunces.

PyramidがZopeに依存している理由が不運な劣等生について書かれたものではない（訳注：フレームワーク上の欠陥ではないという意味？）ことを書いてきた。

If you need a concrete positive replacement, try to think of something like this:

Mac OS X today ships with zope.interface out of the box and that sort of deployment effects more users than you and me put together plus all of our friends (and maybe even all of their friends) will likely ever influence.

Consider that the common wisdom you've gained from Reddit or that guy who used Zope-the-application-server for one day in 2002 may be irrelevant.

訳注：このあたり、ぜんぜん意味わかんない

批評は、あなたがたが最初にPyramidアプリケーションを書くときまでの貸しとしてください。

それでもまだ信じられないのであれば、そのような批評を歓迎します。

ひとまず、ここまでが全文です。ひどい訳ですが、僕が読みすすめたままにメモのような感じで訳してたのでご勘弁を。

In defense of zope libraries 翻訳その２

2011-12-30T14:51:00Z

何年かがすぎたが、Philadelphiaの開発者はソフトウェア工学のいくつかのトピックを気にかけていた。

He notices that if it behooves the industry temporarily, it will tolerate things that are slightly different, but it always holds its nose while doing so and will always retreat back to the familiar at first opportunity.

業界では、すべてのデータベースがリレーショナルでないことに気づいていた。

特に、80年代後半から90年代に掛けて、Smalltalkの喧伝によって、オブジェクトデータベースの可能性が示されていた。

たいしたドキュメントもなかったと記憶している。

Zopeに関するいくつかのことがらが、彼にとっては自明だった。

明確にされたのは、Zope自体の自動テストが必要だということだ。

さまざまなスキルレベルの人たちが十分な品質管理もなく疑問のある追加をしていた。

結果として、自分たちの首を絞めることになった。

あれほど魅力的に見えたweb上での開発モデルも、多くの欠陥を持っていることが明らかになった。

この方法では、自動テストを書くことは困難だった。

TTW(Through-the-web) モデルは、システムと密接にかかわっていたため、webモデルとかかわりのないコードを書くことが困難になっていた。

TTWセキュリティモデルの存在と、管理インターフェイスへの期待は、さらに先進的なコードを書くことをやっかいにしていた。

袋小路に追いやられていた。

なぜなら、新しいZopeユーザーをひきつけているものが、最初にそのシステムで成功した後に、撃退すべきものととらえられてしまっているからだ。

テストしやすいコードを書くためには、Digital Creationsのエンジニアは、Web上での開発やめなくてはならなかった。しかし、Zopeのためのコードをオフラインで書くのは、非常に腹立たしいことだった。

TTWコードモデルは死すべきか、もっと開発をサポートするツールが必要であることが明らかだった。

だが、UNIXで動くような、よりよいツールチェインを作る時間を誰も持っていなかった。

TTWプログラミングモデルは、社内外で幻想だったと感じられていた。

だが、それでも2001年はZopeは非常に成功した。

2001年のSoftware Development MagazineのJolt Product Excellence Awardを勝ち取り、雑誌の表紙をかざった

(この賞をもらったときは、この製品は、とても重要で、企業サイトを作る難しい仕事を速く、早く、さらに効果的にすると書かれていた：訳注よくわかんないけどものすごく賞賛されたようだ)

大きなメディア企業がこのプラットフォーム上にサイトを立ち上げた。

彼らにとって十分なできだった。

Digtal Creationもコンサルティングの成功を十分に受け入れていた。

さらなる利益も十分に得られていた。

主要なZopeメーリングリストは1日あたり100メッセージが流れていた。

メーリングリストのメールを受信を重要なサービスのイベントトリガーにしてもよいんじゃないかとジョークで言っていた。まるで時報のように新しいメッセージが昼夜問わず飛んできていたからね。

Zopeベースの新しいシステムがどんどん作られていた。CMF(Ploneのベースとなっている。)もその１つだ。

そんな感じでときはすぎ、Philadelphiaの開発者は、Zopeの次のバージョンが始まるのを見ていた。Zope3だ。

Zope3は、Zope2と互換性がなくなるようだった。互換性レイヤーはのちに作成されることとなっていた。だが、Zopeは完全に再設計、再構築されたていた。

すべてが書き直され、この作業はDigital Creationsのなかで多くの労力が注がれた。

Zope2を作った主要メンバーはフルタイムで作業した。さらに彼はチームの開発者たちの手助けもした。

Zope3はコンポーネントアーキテクチャをもとにしていた。これは開発してテストしたコンポーネントを入れ替え可能にするものだった。開発者が必要なもの、提供できるものサードパーティから提供されるものを必要に応じて入れ替えることができ、Zope2の柔軟性のなさとは対照的だった。

サブクラスよりも集約が好まれるようになった。ZCMLという、XMLベースのコンフィグレーション言語ですら作り出した。Zope2のような大きく1枚岩なシステムの代わりに、小さな部品の相互作用で構成されるようになった。

Philadelphiaの開発者は、これはすごいものになると核心していた。尊敬する賢い人たちが、これらの作業をしていたからだ。

Philadelphiaの開発者は、Zope3の何百、何千というコードを眺めていた。

開発チームは、よいテストの書き方を学んでいた。(だが、よいドキュメントの書き方には気づいていなかった）

Digital CreationsのすばらしいエンジニアたちはZope3の糞な部分も設計した。

少しずつだが、美しい核を持つ複雑なシステムになっていった。それでも、Zope2とは違っていた。Web開発のその他のものとも、大きく違っていた。

1，2年が経過した。最初のノンベータリリースまでに4年ほどが経っていた。

Zope2はこのときまで、ポピュラーな状態だった、だが、多くの人々はその未来やZope3に不安を抱いていた。

Zope3が最初にリリースされたときには、Philadelphiaの開発者は非常に落胆していた。（彼のDigital Creationsでの仕事は、Zope2を使ったコンサルティングだった）

難しすぎる。全体像がつかめない。貧弱なドキュメント。多くの人たちがいらだちを感じた。

さらに、Zopeを置き換えるようなものも増えていたし、人々はもっと単純に早く適切な代替手段を探し始めていた。

この間に、Digital CreationsはZope Corporationと名前を変えた。そして、少しずつベンチャーキャピタルにフォーカスしたビジネスモデルを欲しがるようになった。コンサルティング料よりも製品で稼ぐことを試みるようになった。

結局、会社はエンジニアリングへの投資を減らしていった（そして営業に注力していくようになっていった）

そして、Zope3の基盤が崩れてしまった。Zope2が使われているプロジェクトがある状態で、新しいZopeを作るための資金が出なくなったからだ。

Zope２とZope３の両方のプロジェクトを開始した主要な支援者は、売れる製品を作ることに注意をはらわないといけなくなった。

サードパーティからZope3へのオープンソースによる支援は重要だったが、Zope Corpolationの後ろ盾はなかった。そしてそれらの影響もあまり見られなかった。

Zope3は決して大きな注目を浴びることはなかった。

コンポーネントアーキテクチャのようないくつかのテクノロジーは、Zope2へと逆移植された。だが、この方法は、ただでさえ複雑だったZope2をさらに複雑にした。

BluebreamやGrokのようなプロジェクトでは、Zope3をベースとしたハイレベルなフレームワークだ。だが、これらもそれほど注目されなかった。

5年におよぶブランド汚しによって、人々はZopeが何なのかわからなくなってしまった。

Zopeとは何か？Zope2か？Zope３のことか？Zope Corporationka？PyPIにあるパッケージのことなのか？パッケージの集まりか？

それぞれすべて真実である。

ブランドネームというのは結局、大きな意味を持たなくなる。すべてを表すと同時になにも表していない。

恐ろしいことに、Djangoなどよくドキュメントがありよく設計されたシステムが登場するようになり、ブランドは急速に蔑みの対象と変わってしまった。

In defense of zope libraries 翻訳その１

2011-12-30T06:29:00Z

追記：2012/01/04

@knzm2011 が全訳してくれました。

http://plope.com/Members/chrism/in_defense_of_zope_libraries の翻訳

1/3くらいまでです。

PyramidがZopeライブラリを使っていることについて

IRCチャンネルで訊かれた以下のような質問について、多くの時間を割いた。

<誰かさん> pyramidはzopeベースだと聞いた。zopeは悪だ。なぜpyramidはzopeベースなのか？

Pyramidはzopeの名前を持ったライブラリを使っている。

より正確にいうと、実際に使っているのは、 zope.interfaceとzope.deprecationの２つだ。

上に書いたようなIRC質問でるのは、少なくない人たちが、 zopeは悪だと考えている証拠だろう。

そして、推移的に、pyramidも悪だと感じるようだ。

もしくは、zopeを消してしまうことで、pyramidがより良くなるだろうと。

だが、そのように白黒付けたがるのはわかるが、実世界はもっと複雑だ。

物事の真実がそんなに単純であれば説明するのも簡単だろう。その方がいい。

だが、そうではない。そして、明確な答えを示す必要があるくらいに、上のようにたびたび質問される。

ただし、説明するとなにかが失われる

だから、かわりに物語として語ることにしよう。

時は1999年、場所はPhiladelphia PA, USのあるソフトウェアコンサルティングの会社で。

20数名のあまり経験のない開発者たちが、地元企業のイントラネットアプリケーションを作成する必要にせまられた。

彼はとても世間知らずだった。手に余ることばかりだった。

彼はPerlでは、どんどん危険になると気づいた。

彼はMySQLをバックエンドに使い、Perlで書いていた。

システム内の関数は、だいたいこんなものだった。

sub get_domains {

my $r = Apache::Request->new(shift);

my %cookiejar = Apache::Cookie->new($r)->parse;

# ... check the cookies for a user id ...

# ... check the userid against a table in the database that

# ... says whether the calling user is allowed to get domains

# ... if not, redirect to login page.

# ... if so, do some inscrutable SQL statement to get the domains

# ... and render them into HTML.

}

これはうまくいかなかった。

金曜日の午後（mod_perlをチューニングするという壮絶な苦しみの最中だった）、

彼は、Slashdotで Zope 1.10という新しいシステムを見つけた。

それはPythonというオープンソースのスクリプト言語で書かれていた。

それは自身をアプリケーションサーバーと称していた。

そして、すばらしい管理画面やセキュリティ機能のスクリーンショットを掲載していた。

彼はこれを試すことにした。

彼は自分のWindows NT用のインストーラーをダウンロードすると、ダブルクリックしてインストールした。

そして、基本的な操作方法にしたがって、管理画面をNetscape Navigator4で開いてみた。

彼は三つのことに感動した。

a) Webブラウザでコードを書ける

b) 非常に先進的なセキュリティモデルを持っていた。

そのため、完全に信用できるわけではない人々にでもWebブラウザからコードを書かせることができた。

そして、Zopeのセキュリティモデルは宣言型だった。

つまり、これらのデータモデルとセキュリティモデルを受け入れてしまえば、mod_perlのアプリケーションで書いていた、決まりきったセキュリティチェックのコードをすべてなくしてしまえた。

リレーショナルデータベースを用意する必要もなかった。専用のオブジェクトデータベースまで含んでいたからだ。

UIは、データベースとコードをツリーとしてグラフィカルに見せてくれた。

これは彼に信じられない天啓のようだった。

そして、彼はこれらの機能によって、今書いているシステムをより早く簡単に作れることを悟った。

彼の技術力の中で、これほどの生産性を持つものはなかった。チャンスだった。

mod_perlで書いたコードはすべて捨ててしまった。

Pythonの知識はまったくなかったが、Zopeのソースや適当なメーリングリストの議論から情報を広い上げ、Zopeを使ってどうにかシステムを作り上げた。

彼は、テストの書き方をまったく知らなかった。

彼の会社にいる人たちも、誰もテストの価値を知らなかった。

だから彼もテストを書いていなかった。

web上でのコーディングあるにもかかわらず、そしてこの仕事の以前にもPythonの知識もほとんどなくかったが、mocl_parlで書いたものよりもよいものになった。

a) Zopeの宣言的セキュリティモデルに完全に頼るようにした。

b) セキュリティの設定を変えるために必要なUIを顧客に見せた。

c)出来上がったシステムは、これまで彼が書いていたものよりも、非常に精密なセキュリティモデルを持っていた。

― セキュリティはコンテキストに依存する。よって、もし誰かがドキュメントをイントラネットに追加したい場合、問題なくそのドキュメント固有の認証情報を持っていなくてはならない。

これを顧客にみせたところ、彼らは非常に気に入ってくれた。

Zopeの新しいバージョンは、バージョン2.0として、すぐにリリースされた。彼は、コードを比較的簡単に移行させることができた。

彼はそれからいくつかのZopeの仕事をこなした。しかし、彼はその後Philadelphiaの会社をやめた。Microsoft製品を取り扱うようになったからだ。

彼は、その後、いくつかの幸運によって、Digital Creationの職を得た。Zopeそのものの開発者となった。

数年のとても良い時間をすごした。

彼はZope 2アプリケーションをさまざまな顧客に向けて書いた。

また、Digital Creationsの同僚やマネージャーたちから多くの（とても、とても良い経験だった）本当のソフトウェアエンジニアリングについて学んだ。

New Years Python Meme #2012pythonmeme

2011-12-29T13:51:00Z

What is the coolest Python application, framework, or library you have discovered in 2011?

I like Pyramid, webob and repoze components.These are the base of modern python web application.

What new programming technique did you learn in 2011?

MVVM pattern.That is used in WPF/Silverlight appplications.I wanna use the architecture like that on pyramid application.On that, the important point is loose coupling.

What’s the name of the open source project you contributed the most in 2011? What did you do?

Pyramid.I contributed some patches for that.

What was the Python blog or website you read the most in 2011?
- Reddit Python Section
- The history of Python
- Python insider
- Fethez le Python
What are the three top things you want to learn in 2012?
- python3 and pysetup3
- html5 and new js apis
- Windows Phone7
What are the top software, app, or lib you wish someone would write in 2012?
I wish some libraries support py3.

They are:
- repoze.who
- PasteScript
- ZODB3

Pythonアドベントカレンダー2011(Python3) 25日目の裏 Pyramid@Python3 日本語訳

2011-12-25T11:11:00Z

このエントリはPythonアドベントカレンダー2011の２５日目として、書いてもらった Pyramid@Python3の翻訳です。

tarekはエキスパートPythonの著者であり、PyconJP2011でもPython3のパッケージングについて基調講演をしていただきました。

以下翻訳です。

pypy cliバックエンドに完敗

2011-12-22T08:21:35Z

さてpypyアドベントカレンダー 22日目ですよ。

このブログのエントリは半分くらいがアドベントカレンダー参加のために書かれています。

pypyはc以外にもjython, CLIのバックエンドがあると聞いて！

ということで、WindowsやらUbuntuやらでがんばってみました。

タイトルどおりまあ、完敗だったわけですが。

まずWindows

とりあえずWindows SDK 6.1で挑戦。

うっかり入っていたMonoを検出されてしまい時間をとられる。

基本的に.NET SDK使おうとしてるようだけど、MonoがあるとアセンブラだけMonoのilasm2使おうとするらしい。でもそんなファイルないですから！

しょうがないので該当部分をちょこっと変えてMonoのことは忘れてもらいました。

そして、ビルド開始。

pypy translate.py -Ojit --backend=cli

として待つこと１０分くらい？

どのくらい進んだかなーと画面を確認したらエラーで止まってました。(´・ω・｀)

UnicodeBuilderReprのll_getlengthがないのが原因のようで。

というかないのは問題ではなく、ないものを使おうとしてるのが問題？

このあたり良くわからないので、他の組み合わせでもやってみました。

ubuntu 64bitで挑戦。

結果として、64bitは long == longlong であるために、型の区別がつかない -> bad overridingエラーという、もう根本的にだめじゃね？というエラーでストップ。

ということで32bit ubuntuで挑戦

エラーです。StringReprのconvertルールが見つからないというエラー。

心折すぎる。

結局どのプラットフォームでもpypy cli のバイナリ生成すらできませんでした。

cliならクロスプラットフォームなので、公式なバイナリが出てくれればいいのですが。

ということで、１周目、２周目と負け続きのエントリでした。

来年はもっとpypyを勉強して言語作成とかの話したい。

次は、@chlere ですね。よろしくお願いします。

mercurialアドベントカレンダー2011 21日目precommit hookでrequirements.txtをチェックする

2011-12-20T17:38:00Z

mercurialアドベントカレンダー２１日目です。

今回は小ネタでいきます。

pythonで開発しているときに、依存するライブラリはsetup.pyに書きますが、テストツールやドキュメンテーションツールはsetup.pyに書かないわけです。

そういうのはrequirements.txtに書いとくのです。

あと、setup.pyには細かいバージョン指定をせずに、これまたrequirements.txtに書くことが多いのですが、開発しているうちにrequirements.txtを更新するのを忘れてしまうわけです。

まあ、こんなのpip freezeしてあげればいいのですが、そんなの機械がやってくれよ！

ということでprecommit hookでrequirements.txtが古くなっていないか確認します。

あと、virtualenvで作業してるのになぜかプロジェクトに関係ないライブラリが入ってしまってないかの確認にもなります。

[hooks]

precommit.freeze = pip freeze | sed "/-e .*$/d" | diff - requirements.txt

非常に不親切なエラーが出ますがまあ、実際の環境とrequirements.txtの内容が違ってたらそのdiffが表示されて、commitされないようになります。

今開発しているものもeditableでインストールしていてpip freezeに含まれますが、 "-e" で始まるので、それをsedで消してから、確認します。

そうしないとリビジョンが含まれているので、毎回diffにひっかかってしまいますからね。

ということで、２１日目の内容はおしまい。

次は@sabo2さんでいいのでしょうか？

python3でwebプログラミングに使えるライブラリ

2011-12-10T13:04:54Z

From Evernote:

python3でwebプログラミングに使えるライブラリ

各フレームワークが対応中といううわさをそこそこ聞きますが、

今すぐpython3でwebプログラミングをしてみたい人もいると思うので、

python3で使えるライブラリを調べてみた。

Webアプリケーションライブラリ

Beaker セッションとキャッシュ
Jinja2 HTMLテンプレート
Mako HTMLテンプレート
MarkupSafe HTMLのエスケープなど
PasteDeploy WSGIアプリケーションの設定ファイル
SQLAlchemy O/Rマッパー
WebDispatch URLやメソッドに対応したディスパッチャ
WebOb リクエストレスポンスオブジェクト

１とおりのライブラリが出揃っているけど、

認証、認可と、フォームライブラリが不足しているかな？

あとPasteDeployは対応しているけどPasteScriptがないので、

コマンドラインツールが足りてない。

weberrorのようなデバッグツール、エラーレポートも欲しいところ。

WSGIサーバー

tornado
cherrypy

paste.httpあたりのポーティングが望まれるところ。

あと、tornadoはpastedeployのエントリポイント持ってない。

（１０行以内で書けるけど）

テストツール

nose ディスカバリやプラグインに対応したテストランナー
Mock モックライブラリ
WebTest 擬似リクエストを使ったWebアプリケーションテストツール

このあたり鉄板の組み合わせが使えるので、あまり不満はない。

ドキュメンテーション

docutils
Sphinx

docutilsはCategoriesに入ってないけど実際はpy3k対応されている。

まとめ

Webアプリケーションを書くにはまだちょっと足りない印象。

が、Webアプリケーションフレームワークを作るのには十分な下地ができてると思う。

各フレームワークがpython3対応したバージョンをリリースするのも近い。

とはいえ、実用で使おうと思うとサーバーに悩みます。

早くgunicornが対応してくれれば....

さて、アドベントカレンダーの次は @t2y さんにまわします。

よろしく。

その他、python3に対応を表明しているものは以下のリンクから一覧を確認できる。

http://pypi.python.org/pypi?:action=browse&c=533&show=all

pypyでZODBを動かそうとした

2011-12-09T18:14:00Z

はろーえぶりわん

pypyをはじめようとしてそのまま日がたち、アドベントカレンダーで一念発起してpypyをいじっているaodagです。

さて、アドベントカレンダーが回ってきましたが、ほかのみんなのようなpypyで処理系を！ということはあんまり考えてないわけです。

pypyがcpythonよりも速いと聞いてきました！

さてpypyはpyramidですでに公式サポートしているので、まあpypy使えますよねというところですが、ZODBが動かないわけです。

動かないので、動かすためにあがいてみました。（まだちゃんと動かせていません。）

まずはこちらのmlポストを見て欲しい

https://mail.zope.org/pipermail/zodb-dev/2011-September/014364.html

手順が書いてあります。

ということでそのままやってみます。

>>>> storage = FileStorage('data1.fs')
>>>> from ZODB.DB import DB
>>>> db = DB(storage)
>>>> conn = db.open()
>>>> root = conn.root()
>>>> root
Traceback (most recent call last):
  File "", line 1, in 
  File "/home/aodag/Envs/pypypy/lib-python/modified-2.7/UserDict.py", line 15, in __repr__
    def __repr__(self): return repr(self.data)
  File "/home/aodag/Envs/pypypy/site-packages/persistent/mapping.py", line 30, in __get__
    return self.func(inst)
  File "/home/aodag/Envs/pypypy/site-packages/persistent/mapping.py", line 99, in data
    data = self.__dict__.pop('_container')
KeyError: '_container'

だめでした(´・ω・｀)

でもこれってpypyだからだめなの？

ひょっとして、このブランチがだめなんじゃないの？

ということで、このブランチをcpythonで試してみました。

まずはパッチなしの場合。

python2.6では動きます。

python2.7でも動きました。

さて、パッチ適用後です。

python2.7で動きました。

pypyのバージョンが関係しているかもしれませんが、このあたりで心折れたので（日付変わっちゃってるし(´・ω・｀) ）ZODB動かす夢はまた情報が入ったら試すことにします。

残念な結果になりましたが、ひとまずアデュー。

pyramid アドベントカレンダー　１日目

2011-12-01T15:47:53Z

Pyramidとは

PyramidはWebアプリケーションフレームワークです。

2011年に1.0, 1.1, 1.2 とハイスピードで開発が進み、現在の最新バージョンは1.2.3です。

Pyramidの特徴

Pyramidは、ミニマリズムを原則としています。

そのため、ある設定をするだけでいきなりなにかが動き出したり、ちょっと呼ぶだけで自動でいろいろなものが設定されたりすることはほとんどありません。書いたまま動きます。

Pyramidの利点は拡張性です。

ありとあらゆる場所にフック可能で、リクエストオブジェクトやセッション、DB接続など、あらゆるフレームワークの動きを変更可能です。

また、こうしたフックは自分のアプリケーションでも利用可能で、拡張性の高いアプリケーション作成に非常に役立つものと思います。

小さなアプリケーションは小さく書けることを目標においています。

実際、helloworldのようアプリケーションはWebサーバーの起動まで含めて１ファイルに収めることも可能です。

目的に合わせてできることを制限したフレームワークは非常に便利です。その目的に合わせたアプリケーションを書く限りは....。

フレームワークの制限に泣いたことのある人、昔ながらのCMS的なWeb+DBサイトのフレームワークを使うことに限界を感じている人。

また、単に新しいフレームワークを知って知見を広めたい人。

Pyramidをぜひ触ってみてください。

インストール

今後説明する環境はubuntuに限定します。

WindowsやMacの方は、VirtualBoxやVMWarePlayerで環境を用意してください。

build-essentialとpython-devが入ってることを確認しておきましょう。

$ wget http://python-distribute.org/distribute_setup.py

$ python distribute_setup.py

$ easy_install virtualenv --user

$ easy_install virtualenvwarpper --user

$ cat >> ~/.bashrc
export WORKON_HOME "$HOME/.envs"
mkdir -p "$WORKON_HOME"
export VIRTUALENV_USE_DISTRIBUTE=1
source ~/.local/virtualenvwrapper.sh
^D
$ source ~/.bashrc

とりあえず動かす

実際に環境を作ってpyramidを動かしてみます。

$ mkvirtualenv --no-site-packages pyramid
(pyramid)$ pip install pyramid
(pyramid)$ paster create -t pyramid_starter mypyramid
(pyramid)$ cd mypyramid
(pyramid)$ pip install -e .
(pyramid)$ paster serve development.ini

http://locahost:6543 にアクセスすると、Pyramidのデフォルトページを見れるはずです。

１日目からいきなり遅れてしまいましたが、２日目以降はPyramidのいろいろな話題を12/25まで取り上げていく予定です。

2011 Pythonアドベントカレンダー

2011-11-26T07:30:00Z

やるぜ！

https://connpass.com/event/142/

Python3でPyramidを動かしてみよう

2011-10-22T08:19:09Z

githubのリポジトリから直接インストールします。

pip install git://github.com/Pylons/pyramid.git#egg=pyramid

インストール後のパッケージ状況

Chameleon==2.5.2
Mako==0.5.0
MarkupSafe==0.15
PasteDeploy==1.5.0
WebOb==1.2b2
distribute==0.6.19
-e git://github.com/Pylons/pyramid.git@b75e577383936454d8b3e912f4f5478bf9af01e6#egg=pyramid-dev
repoze.lru==0.4
translationstring==0.4
venusian==1.0a2
wsgiref==0.1.2
zope.deprecation==3.5.0
zope.interface==3.8.0

main.py

from pyramid.config import Configurator
from wsgiref.simple_server import make_server

def index(request):
request.response.text = "hello, world"
return request.response

config = Configurator()
config.add_view(index)
app = config.make_wsgi_app()

httpd = make_server('0.0.0.0', 8080, app)
httpd.serve_forever()

ひとまず簡単なアプリケーションは動きました。

Pyramid1.2リリース！

2011-09-13T10:11:28Z

(´　　＞　ω　＜　)Pyramid1.2リリースだよーーーー！

インストールするには

pip install pyramid==1.2

easy_install pyramid==1.2

変更点の細かいところは、公式を見てもらうとして、大きな変更点を紹介するよ！

debug toolbar

*あの* Django の debug toolbar を移植したもの。

SQLAlchemyのクエリデバッグにも対応してます。

これまでブラウザ上で対話的なデバッグに使われていた WebError はここで引退？ということになるのか。

WebErrorのデバッグ機能はdebug toolbarに、メール通知などはpyramid_exclogに分割されました。

PasteScriptで生成するプロジェクトテンプレートも、 debug toolbar を使うように変更されてます。

route_prefix

PyramidはConfigurator.includeで別アプリケーションをインクルードできるようになっていたのですが、URLのルーティングは完全にグローバルな状態でした。

今回、includeメソッドでroute_prefixを追加することで、サブアプリケーションがあるURL以下にマッピングされるようになります。

たとえば、 include('admin', route_prefix='/admin') とすることで、 adminアプリケーションの、 'login' などは、 '/admin/login' とマッピングされるようになります。

tween

tweenはWSGIミドルウェアのPyramid版といったもので、 Viewを包み込んでリクエストの処理を行えます。

WSGIミドルウェアとの違いは、リクエストオブジェクトやレンダラーのようなPyramid機能を使えるというところ。

CSRF処理の追加や、リクエストオブジェクトへの情報付加など、いろんなことができますね。

route_prefixとtweenで、アプリケーションの拡張性や再利用性がぐんとあがったように思います。

そろそろ仕事で使ってもいいかもね。

https://docs.pylonsproject.org/projects/pyramid/1.2/whatsnew-1.2.html

PyCon JP 2011 資料リンク

2011-08-27T15:35:00Z

恒例の資料リンク集め

UST

http://www.ustream.tv/channel/pyconjp1

http://www.ustream.tv/channel/pyconjp2

http://www.ustream.tv/channel/pyconjp3

C APIへの誘い cocoatomo

https://docs.google.com/present/view?id=dchk96tc_2ftxfgqck

Webフォームウィジェットツールキットを総括する aodag

http://www.slideshare.net/aodag/form-libraries-9031180

Pythonエンジニアの作り方 tkOmiya

http://www.slideshare.net/TakeshiKomiya/python-201108-pyconjp

Asynchronous Python Programming Ian Lewis

http://ianlewis.bitbucket.org/pyconjp_2011_slides/template/index.html#1

Pythonを使った次世代組み込みシステム Yuta Kitagami

http://www.slideshare.net/yutakitagami/pycon-jp2011-yuta-kitagami

Pythonによる日本語自然言語処理 nokuno

http://www.slideshare.net/nokuno/python-pyconjp

PyQtではじめるGUIプログラミング RansuiIso

http://www.slideshare.net/RansuiIso/pyqtgui

Openspace

フレームワークなしでWSGIプログラミング aodag

http://www.slideshare.net/aodag/wsgi

wsgi forms

2011-08-02T11:41:02Z

このあたりで比較していこうと思う

Pythonの相対インポートなど

2011-07-03T09:57:00Z

import .baconとかfrom . import egg とかの書式ってなんなんだ？という疑問を小耳に挟んだので、なんかがんばっちゃうよ。

spam/egg.pyからspam/bacon.pyをインポートするときって、import baconとか書いちゃうよね。

だが、ちょっと考えてみて欲しい。

bacon.py
spam/egg.py
spam/bacon.py

こんな構成の場合はどうなるだろう。

spam/eggからimport baconすると、

このときのbaconは、spam/bacon.py だ。

このとき bacon.py は、spam/bacon.pyにかくされてしまっている。

じゃあ、トップレベルにあるbacon.pyはどうすればインポートできるのか？

こうした問題を解決するのがPEP328

http://www.python.org/dev/peps/pep-0328/

まずは、 from __future__ import absolute_import を使った場合と使わない場合。

absolute_import がない場合は、そのモジュールと同じパッケージにあるモジュールが優先される。

この場合、soam/bacon.pyに隠されてしまうため、トップにある bacon.pyは、__import__とか面倒なことをしないとインポートできなくなる。

absolute_importがある場合は、import baconってのは、トップレベルにbacon.pyがないといけない。

また、このとき同じモジュールにbacon.pyがあってもインポートできない。

spam/bacon.py は、 from spam import bacon ってインポートする。

from spam import bacon って書き方はどちらの場合でも通用する書き方だけど、

パッケージの名前を変えたいときに、全部書き換えないといけなくなる。

このため、相対importであることを明示する方法がPEP328で追加されている。

from . import bacon と書くと、そのモジュールが属するパッケージからbaconをインポートする。

ちなみに、python3.xだと、デフォルトでabsolute_importになっている。

python2,3両方に対応する場合、相対インポートを意図している箇所は、明示的に相対インポートの書式にしましょうということ。

わかったかな？tell-kさん？

aodag's posthaven

pytest, mock, testfixture!

新年的なアレ

From Evernote:

新年的なアレ

New Year's Python Meme 2012 #2012pythonmeme

From Evernote:

New Year's Python Meme 2012 #2012pythonmeme

2012の新年のあれがどうなったか

PySPAアドベントカレンダー

From Evernote:

PySPAアドベントカレンダー

IT業界Heavy Metal Advent Calendar 2012 22日目

2012 Pythonアドベントカレンダー 18日目 PasteDeployを知ってるかい？

From Evernote:

2012 Pythonアドベントカレンダー 18日目 PasteDeployを知ってるかい？

virtualenvなしでもプロジェクトごとのライブラリを管理する方法 #python

BPStudy #54で発表してきたよ！

Python2.4から3.2までで通用するexcept句の書き方

pyramid_formalchemyでpyramidにもadminアプリを！

過去記事をまとめた

Pyramidを拡張する作法 知識編

新年のアレ

In defense of zope libraries 翻訳その３

In defense of zope libraries 翻訳その２

In defense of zope libraries 翻訳その１

New Years Python Meme #2012pythonmeme

Pythonアドベントカレンダー2011(Python3) 25日目の裏 Pyramid@Python3 日本語訳

pypy cliバックエンドに完敗

mercurialアドベントカレンダー2011 21日目precommit hookでrequirements.txtをチェックする

python3でwebプログラミングに使えるライブラリ

From Evernote:

python3でwebプログラミングに使えるライブラリ

pypyでZODBを動かそうとした

pyramid アドベントカレンダー １日目

Pyramidとは

Pyramidの特徴

インストール

とりあえず動かす

2011 Pythonアドベントカレンダー

Python3でPyramidを動かしてみよう

Pyramid1.2リリース！

PyCon JP 2011 資料リンク

wsgi forms

Pythonの相対インポートなど

Pyramidを拡張する作法知識編

pyramid アドベントカレンダー　１日目