いまは世界中でPyConが開催されています。PyConというのはPython Conferenceのことです。それらの中でも一度は行ってみたいと思うのがPyCon（US）ではないでしょうか。

筆者が参加したPyCon 2012は、アメリカのカリフォルニア州サンタクララにあるSanta Clara Convention Centerというイベント会場で開催されました。ハイテク企業の聖地、いわゆるシリコンバレーと呼ばれる地域にあります。来年のPyConもサンタクララで開催されることが決定しています。

本稿の読者もPyConへ行こうと思ったときにその全体像が分かるよう、筆者視点でPyCon US 2012のレポートをお届けします。

Travel：旅行

参考までに渡航記録をまとめておきます。筆者は一人旅行だったのですが、カンファレンス期間のほとんどを、カンファレンス会場に併設されたホテルで宿泊しました。

海外のカンファレンスに参加した経験がない方は、カンファレンス会場と同じホテルに宿泊することを筆者はお奨めします。というのは、次のようなメリットがあります。

• （特に初日は）移動や会場探しで迷う心配がない
• 荷物が多くなったら部屋に置いてこれる （⁠受付後や展示ブースでパンフレットやノベルティをたくさんもらう）
• 忘れものをしても取りに行ける
• カンファレンス中に疲れたら部屋へ戻って休める
• 遅くまで会場に残ってイベントに参加したり、他の参加者とやり取りできる

同じホテルに泊まることで移動やちょっとしたトラブルを避けることができるかもしれません。

筆者が本カンファレンスへ参加するのにかかった費用は次の通りです。

合計すると204,531円になります。為替が1ドル80円程度でした。この中に食費は含まれていませんが、今回のカンファレンスでは、朝食・昼食共に提供されていました。カンファレンスの参加費は、企業／個人／学生の3つの区分に分かれています。私は個人で参加しましたが、（⁠早期申し込みで）企業が支払う場合は$450、学生なら$200になります。

往路は成田 - ロサンゼルス - サンノゼと空路で移動しましたが、復路はサンタクララから電車でサンフランシスコへ移動し、サンフランシスコから成田への直行便にしました。サンタクララ - サンフランシスコ間は、カリフォルニア高速鉄道の普通電車で1時間20分でした。電車が空いていたのと、車窓からの眺めが良くてとても快適でした。

PyCon 2012 概要

PyCon 2012は、大きく3つのフェーズに分けられます。

3月7日、8日の2日間はチュートリアルです。チュートリアルというのは、有償のセミナーです（1つにつき$150⁠）⁠。3月9～11日の3日間がカンファレンスのメインとなる講演です。基調講演を始め、様々な講演やライトニングトークスがありました。3月12～16日の4日間がスプリントという参加者の有志によりグループ（プロジェクト）単位に分かれ、それぞれのテーマに取り組む開発イベントです。スプリントは主にその対象のプロジェクトのバグ修正や機能拡張を行います。

Tutorial：チュートリアル

チュートリアルは、8部屋 x 2（午前／午後）x 2日間 = 32個のセッションがありました。初心者向け、経験者向け、内容も様々なものが用意されています。

試しにGraph Analysis from the Ground Upという、初心者向けのグラフ解析のチュートリアルを受講してみました。講師はVan Lindbergです。時間は3時間20分、参加者は40人程でした。

グラフとは、点と線から成り、点に名前を付けて、それらを紐付ける線に意味付けしたものだと説明していました。この考え方は、世の中の色んなものごとに対して適用できて便利なツールになります。データを解析するにあたってグラフでモデリングして解くという考え方そのものが、筆者にとってはこれまで触れたことがないもので新鮮でした。

チュートリアルでは、グラフ理論の基礎、身近な例の紹介、networkxを使ったPythonでのプログラミングなどを行いました。例えば、networkxを使って、ディレクトリ構造をグラフで表現すると次のようになります。

$ tree foo
foo
├── bar
│   ├── baz
│   │   └── f1
│   └── f1
├── f1
├── f2
├── f3
└── hoge
     ├── f1
          └── f2

import os
import networkx as nx
import matplotlib.pyplot as plt

def build_fs_graph(directory):
    g = nx.Graph()
    for root, dirs, files in os.walk(directory):
        for node in dirs + files:
            g.add_edge(root, os.path.join(root, node))
    return g

g = build_fs_graph("foo")
nx.draw(g)
plt.show()

講師のVan Lindbergは一般の講演も行っていて、そのセッションではPython-Devメーリングリストの以下のような事柄に対して、どのようにグラフでモデリングして解析するかを解説していました。

• 誰と誰がよく話しているか
• メーリングリストの中で関心の高い話題は何か
• “最適化”という話題に対して最もコメントしている人は誰か

以下から講演内容とビデオが参照できます。

• Graph Processing in Python［内容/ビデオ］

PyWeb Summit：PyWebサミット

3月9日にチュートリアルとは別にPYTHON WEBDEV SUMMITというパネルディスカッションがありました。PythonによるWeb開発に関する様々な話題について、それぞれのプロダクトの開発者が集まって議論するイベントでした。

丸1日に渡り、6つの話題について議論されていました。一番最初のWebアプリケーションのデプロイについて紹介します。このパネルディスカッションのパネリストには、PyCon JP 2011で基調講演をしているTarek Ziadeもいます。

モデレーターのJacobからJavaのWARファイルでデプロイするような仕組みがPythonにはないという話しから議論が始まりました。

それに対してIan BickingのPython application packageのアイディアという記事を受けて、Pythonアプリケーションのデプロイで標準的な方法を確立するための議論がなされました。設定ファイル、依存関係、エントリーポイントの定義をどうするかという観点で、この話題はWebアプリケーションに限ったものではないという意見もありました。

また、Pythonパッケージではない外部ライブラリの依存関係をどうするかについて、Python 3.3で導入されるpackagingライブラリでは、Requires-Externalというメタデータでそのヒントを与えられます。ただし、RedHatのRPMやDebianのdebパッケージでは、そのパッケージ名が違うためにRequires-Externalを使ってインストールを自動化できるかどうかは懐疑的なようです。

またC拡張ライブラリを必要としないPythonアプリケーションであれば、比較的デプロイは簡単ですが、そうではない場合だとコンパイルが必要だったり、依存関係が複雑になったりするため、なかなか難しいです。

最終的にパネルディスカッションのまとめとしては、多くの人が興味をもっている話題なので、デプロイの標準方法の仕様の草案に取り組もうといったものでした。

興味のある方は、TarekによるWebDev Summit Reportも参考にしてください。

Introduction：開会の挨拶

カンファレンスの基調講演の前に、運営統括のJesse Nollerからの開会の挨拶がありました。参加者は2,257人、スポンサーとパートナー併せて136社（組織）という、過去最大規模の10th PyConだったそうです（毎年拡大している説もあります⁠）⁠。

彼はPyConの運営にあたって、彼の家族、友人、職場の同僚、そしてコミュニティメンバーのたくさんの人に助けてもらったことを話しました。実際にこの規模のイベント運営を行うのは、相当な労力を要するのが容易に伺えます。彼の娘の写真をスクリーンに写しながら、心暖まるような内容でした（日本だと、家族を紹介したりといったプライベートなことを公の場で紹介しない傾向にあると思います⁠）⁠。

個人の背景を述べながら、私たちのいまがあることにみんな感謝しようという雰囲気作り、そして巻き起こるスタンディング・オベーション。始まりの雰囲気が感動的でとても良かったです。

そのビデオがIntroduction and Welcomeです。Jesse Nollerは4分過ぎから登場します。また、ビデオの前半はオープニングイベントとしてAldebaran Robotics社のNAOというロボットが会場を盛り上げてくれました。このロボット操作もPythonでプログラミングできるそうです。

Keynote：基調講演

3日間に及ぶカンファレンスでは、いくつかの基調講演が行われました。ここでは、その中から2つを紹介します。

Frighteningly Ambitious Startup Ideas（とんでもない起業家たちのアイディア）

ハッカーでありエッセイストでもあるPaul Grahamの基調講演です。Paul GrahamとPythonで筆者が思い浮かべるのは、Pythonのパラドックス —The Python Paradoxです。PyCon 2003の基調講演以来の、PyConで2回目の基調講演だそうです。講演内容はFrighteningly Ambitious Startup Ideas（和訳）から読むことができ、そのビデオはKeynote Paul Graham,YCombinatorで公開されています。

彼が驚く起業家たちのアイディアとして、次の7つが挙げていました。

• 新しい検索エンジンを作る（4:10）
• Eメールを置き換える（7:30）
• 大学を置き換える（11:50）
• ハリウッドをやっつける（13:45）
• 新しいApple（17:10）
• ムーアの法則に戻る（21:00）
• 継続的な診断（26:25）

基調講演の内容がエッセイとして公開されているというのも珍しい気がします。それぞれのタイトルだけを見ると「無理でしょう？」と思うようなものに対して、彼ならこういう視点から突破口を見い出し、そうでもないかもしれないと述べています。

最後に戦略的なアドバイスとして、大きなアイディアに対して未来を正確に見通すのようなやり方よりも、曖昧なビジョンで取り組む方が実際にはうまくいくものだとまとめていました。

つまり、絵空事のように思えるぐらいがちょうど良いということかもしれません。

Paul Graham PyCon 2012 keynote | Hacker Newsでもたくさんコメントが寄せられています。

BDFL Keynote：慈悲深き終身独裁者の基調講演

Pythonの作者であるGuido Van Rossumの基調講演です。ビデオはKeynote Guido Van Rossumで公開されています。

冒頭にGuidoの心を打ったアートとして、Yuko Honda（@yukop）さんによるPSFロゴのラテアートを紹介しました。

本題はPythonに対して、嫌がらせのような質問をする人たちをTroll（トロール）と呼び、そんな人たちの質問への回答からPythonという言語の本質を学ぼうという内容でした。

• 言語の比較（5:15）
• Python 3（7:35）
• PyPy（12:30）
• 動的型付け（18:40）
• 速度（26:00）
• GIL（32:30）
• 非同期 I/Oと並列性（36:35）
• ブラウザ（41:30）
• モバイル（42:30）
• 関数型プログラミング（44:25）
• 標準ライブラリ（49:00）
• ガベージコレクション（53:55）
• 言語の進化（55:30）

これらの質問の中から筆者が興味深かったものを紹介します。

Language Comparisons（言語の比較）

• "Python sucks. Ruby Rules."
  （Python キモイ、Ruby こそ最高だ）

PythonはPerl/Rubyと正に同じ言語である、それはどのコミュニティも活発で、似たような運営を行い、目的とするものも同じだと説明しました。そして、Java/C++がこれらのスクリプト言語と比較して全く違う言語と言うのは、その哲学やコミュニティの成り立ちが違うからだとも言及しました。

誰もがお気に入りの言語が良いものだと誇りたいのは分かるけれど、他の言語と比較して軽蔑するのはよくない、みんな仲良くすべきだと呼びかけていました。

Python 3

• "When will you admit Python 3 is mistake?"
  （いつPython 3は間違いだと認めるのか？）
• "When will we finally get to see Python 2.8 release?"
  （いつPython 2.8を目の当たりにできるのか？）

Python 3は良いものであるし、NumPyを始め、多くのライブラリのPython 3への移行は着実に進んでいると紹介しました。ちなみにPython 2.8は決してリリースされません（PEP 404 – Python 2.8 Un-release Schedule⁠）⁠。

そしてPython 2.xとの後方互換性のために導入する機能として、PEP 414 – Explicit Unicode Literal for Python 3.3で承認されたPython 3.3でユニコードリテラル（u”文字列”）を扱えるようにする変更についても説明しました。

3月9日のPYTHON WEBDEV SUMMITのパネルディスカッションでもPython 3への移行についての議論があり、Guidoもパネリストとして参加していました。その議論の中でも、Python 3への移行について、1つのベストプラクティスにこだわる必要はなく、2to3/3to2、ブランチを分ける、シングルコードベース、色んなやり方があり、それぞれのプロジェクトにあった方法を選択すれば良いと回答していました。

Functional Programming：関数型プログラミング

• "Why did you kill reduce()?"
  （どうしてreduce()をなくしたの？）
• "Please fix lambda."
  （lambdaを何とかして）
• "Please add more functional features."
  （もっと関数型の機能を追加して）

Guidoも関数型言語が大好きで、純粋関数型言語のHaskellは、とても素晴らしくて、ダイヤモンドのようにきれいなコードが書けると例えていました。しかし、Pythonが関数型言語ではなく、手続き型言語であり続けるのには理由があると話します。

Pythonは、ファイルをコピーするといったシステム管理から、Webサーバーを書いたりと、いろんな場面で簡単に使えることを目的にしています。関数型言語であるかどうかよりも、関数型プログラミングの機能や概念を学び、そのプログラミングスタイルを使うのが良いと主張しました。

またPythonにもmapやlambdaといった組み込み関数など、Haskellから取り入れているユーティリティ関数があります。PythonでもHaskellと全く同じようにプログラミングできるかもしれないけれど、きっとそんなことをしても遅いだろうし、すべての処理を純粋な関数型プログラミングで行うこともないだろうと述べていました。

Talks：講演

カンファレンスの講演は5つのトラック（カンファレンスのスケジュール）に分かれて行われました。これらの講演のビデオは、PyCon 2012のビデオアーカイブからリンクを辿ることができます。

筆者は主にテスト関連の講演に参加したため、そこからいくつか抜粋して紹介します。

pytest - rapid and simple testing with Python：Python での速くて簡潔なテスト

発表者はpytest作者のHolger Krekelです。

pytestは以下のすべてのテストフェーズに適用できるツールです。

• ユニットテスト（1つの関数/クラス単位のテスト）
• インテグレーションテスト（複数の機能に対するテスト）
• システムテスト（一連の、ブラックボックスのようなテスト）

pytestの特徴として以下の3点を挙げていました。

• Cross-Python
  • Python 2.4-2.7,Pthon 3,PyPy,Jythonのサポート
• Pythonicスタイル
  • xUnit/JUnitではないPythonらしいシンプルなスタイル
• テストリソースインジェクション
  • テスト関数やその引数をフックするユニークなDI（依存性の注入）

以下から講演内容とビデオが参照できます。

• pytest - rapid and simple testing with Python［内容/ビデオ］

pytestの特徴をサンプルコードと共に簡単に紹介します。

分かりやすいassertレポート

様々なデータに対してassertに失敗するデモプログラムを実行してみます。

$ pip install pytest
$ hg clone ssh://[email protected]/hpk42/pytest
$ cd pytest
$ py.test doc/example/assertion/failure_demo.py

pytestの優れた特徴の1つがテストに失敗したときのレポートです。次のtest_generative()関数ではparam1とparam2という変数を用いてassertに失敗したときにその変数の値を表示しています。

________________________ test_generative[0] ________________________

param1 = 3, param2 = 6

    def test_generative(param1, param2):
    >       assert param1 * 2 < param2
    E       assert (3 * 2) < 6

文字列同士の比較では、差異がある箇所を表示してくれます。

__________ TestSpecialisedExplanations.test_eq_long_text ___________

self = <failure_demo.TestSpecialisedExplanations object at 0x10194a510>

    def test_eq_long_text(self):
            a = '1'*100 + 'a' + '2'*100
                    b = '1'*100 + 'b' + '2'*100
                    >       assert a == b
                    E       assert '111111111111...2222222222222' ==
                    '1111111111111...2222222222222'
                    E         Skipping 90 identical leading characters in diff
                    E         Skipping 91 identical trailing characters in diff
                    E         - 1111111111a222222222
                    E         ?           ^
                    E         + 1111111111b222222222
                    E         ?

同様に、ディクショナリ等においても差異がある箇所を表示してくれます。

_____________ TestSpecialisedExplanations.test_eq_dict _____________

self = <failure_demo.TestSpecialisedExplanations object at 0x10194ab10>

    def test_eq_dict(self):
    >       assert {'a': 0, 'b': 1} == {'a': 0, 'b': 2}
    E       assert {'a': 0, 'b': 1} == {'a': 0, 'b': 2}
    E         - {'a': 0, 'b': 1}
    E         ?               ^
    E         + {'a': 0, 'b': 2}
    E         ?

リソースインジェクション

リソースインジェクションというxUnit/JUnitのフィクスチャテストとは違う仕組みを提供しています（unittestも一部の機能をサポートしています⁠）⁠。

一時ディレクトリ／ファイルを使ったテスト

tmpdirという引数名を使うことで一時ディレクトリ／ファイルを使ったテストを簡単に行えます。次の例ではtmpディレクトリ配下に“test.ini”ファイルを作成し、Configオブジェクトの属性をテストしています。

from ConfigParser import ConfigParser

class Config:
    def __init__(self, path):
        parser = ConfigParser()
        parser.read(path)
        self.extensions = parser.get("myscan", 'extensions').split()

def test_config_defaults(tmpdir):
    path = tmpdir.join("test.ini")
    path.write("[myscan]\n")
    path.write("extensions = .txt .rst", mode="a")
    config = Config(path)
    assert config.extensions == [".txt",]

パラメーターテスト

いわゆるデータ駆動テストです。デコレーターで任意の引数名に対してテストデータを渡します。

import pytest

@pytest.mark.parametrize("numiter", range(10))
def test_func(numiter):
    assert numiter < 9

フィクスチャを分割するテスト

テスト関数とフィクスチャ定義のスクリプトを分割できます。conftest.pyにpytestのフック処理を記述すると、ディレクトリ単位で有効になります。

例えば、テスト関数に対するparamという引数の変数名をフックしてテストデータとしてリストを返す処理をconftest.pyに記述します。

例えば、次のようにconftest.pyとtest_param.pyを作成します。

# conftest.py の内容
def pytest_funcarg__param(request):
    return range(42)

# test_param.py の内容
def test_param(param):
    print("\nparam length is {0}".format(len(param)))

test_param.pyを実行します。長さ42のリストが渡されています。

$ py.test -v -s test_param.py
...
test_param.py:2: test_param
param length is 42
PASSED

実用的な機能としてFuncargRequest.cached_setup()のscopeにより、テストリソースのキャッシュの有効範囲を制御できます。また、次のサンプルではscopeをコマンドライン引数で指定できるようにpytest_addoption()で引数パーサーの処理をフックします。

# conftest.py の内容
def pytest_addoption(parser):
    group = parser.getgroup("general")
    group.addoption('--scope',
           action="store", dest="scope", default="module",
           type="choice", choices=["module", "function"],
           help=("set scope, default: module."))

def mysetup():
    return range(42)

def pytest_funcarg__param(request):
    scope = request.config.option.scope
    print(", scope is {0}".format(scope))
    return request.cached_setup(setup=mysetup, scope=scope)

# test_param.py の内容
def test_param1(param):
    print("id is {0}".format(id(param)))

def test_param2(param):
    print("id is {0}".format(id(param)))

test_scope.py を--scope=moduleで実行します。mysetup()で作成したリストがキャッシュされます。

$ py.test -v -s --scope=module test_scope.py
...
test_scope.py:2: test_param1 , scope is module
id is 4321280584
PASSED
test_scope.py:5: test_param2 , scope is module
id is 4321280584
PASSED

test_scope.pyを--scope=functionで実行します。今度はテスト関数単位でリストが作成されたことが分かります。

$ py.test -v -s --scope=function test_scope.py
...
test_scope.py:2: test_param1 , scope is function
id is 4321280584
PASSED
test_scope.py:5: test_param2 , scope is function
id is 4321283752
PASSED

講演の中では、ネットワークを介したテストを行う際にscopeにより、テストの実行時間が変わってくる例を紹介しました。

pytestプラグイン

設定ファイル、コマンドライン引数お指定、テスト関数の実行、レポート表示の至るところでフックできるのでpytestプラグインも充実していることを挙げていました。

• pytest-xdist：分散テストを目的としたプラグイン
  • テストを複数プロセスで並列に実行する
  • ファイルの変更を監視して失敗したテストのみを再実行する
  • リモートホストにrsyncして複数環境でテストする
• pytest-pep8：pep8でコーディングスタイルをテストする
• pytest-cov：coverageでテストカバレッジを出力する
• pytest-timeout：テストにタイムアウト設定を行う
• oejskit：JavaScript向けのテストツール

Fast Test、Slow Test：速いテスト、遅いテスト

発表者はGary Bernhardtです。テストの目的は次の3つにあるというのが分かりやすかったです。

1. リグレッションを防ぐ
2. （リファクタリングに対する）不安を防ぐ
3. 悪い設計を防ぐ

実際にテストコードを書くときは、ボトムアップ（最下部のassert文）から書く方が簡単で理にかなっていると、その過程を説明しました。

あるWebアプリケーションでSeleniumによるシステムテストに約10秒要したのが、ユニットテストに置き換えることで約1秒に短縮できたと比較しました。また、システムテストが10%で、ユニットテストが90%といった割合が良いと推奨しました。

以下から講演内容とビデオが参照できます。

• Fast Test、Slow Test［内容/ビデオ］

Gaining Confidence through Security Testing：セキュリティテストで信頼性を高める

発表者はGeremy Condraです。次のようにセキュリティテストを定義していました。

• “normal tests + adversary -> security tests”

adversaryという単語を筆者は初めて知ったのですが、直訳すると「敵対者」なので、セキュリティの脅威となる者を指すのでしょうか。

そして、2011 CWE/SANS Top 25 Most Dangerous Software Errorsの中から、脆弱性を防ぐためのテストの方法について紹介しました。特にfuzzdbというテストツールと次の攻撃に対するテストコードを解説していました。

• コマンドインジェクション
• クロスサイトスクリプティング
• ディレクトリトラバーサル

セキュリティに特化したテストという、とても重要なのにあまり知られていない内容で興味深かったです。普通のテストの次のステップとしてもっと広まると良さそうです。

以下から講演内容とビデオが参照できます。

• Gaining Confidence through Security Testing［内容/ビデオ］

PyPy

筆者がPyPyに疎くて詳しく紹介できないのが残念ですが、カンファレンス全体を通して多くのセッションでPyPyの話題を聞きました。PyPyの革新的な成果、Pythonコミュニティにおける関心の高さ、用途によりCPythonの数十倍から数百倍の速度が導くアプリケーション適用の可能性、今後もっともっと身近になりそうな勢いを感じました。普通のアプリケーション開発にPyPyを選択する日がそう遠くないかもしれません。

また、2日目のDavid Beazleyの基調講演はLet’s Talk About PyPyでした。PyPyの講演のリンクのみを紹介します。

• Why PyPy by example［内容/ビデオ］
• How the PyPy JIT works［内容/ビデオ］

日本においてもpypy-jaが活発に活動しているので要チェックです。

Testing In Python Birds of a Feather / TiP BoF

カンファレンス初日の全講演が終わった後でオープンスペースのTesting BOFに参加しました。オープンスペースというのは、「⁠やりたいこと、話したいこと」のある参加者（グループ）が、部屋と時間を確保して自由に催しをする場のことを指します。アンカンファレンスとも呼ばれるようです。

Testing BOFは、テストに関することなら何でもありのライトニングトークスでした。発表者が30人以上、聴衆が120人程といった大きな集まりでした。最初の発表はTop 10 Reasons Non one use for testing（誰もテストしたがらない10の理由）から始まりました。プレゼンテーションもうまかったので、みんな盛り上がって笑っていました。

10. テストツールがビヘイビア駆動開発（behavior driven development）だ
9. テストツールが継承とCamelCaseを要求してる、それはJavaじゃないのか
8. ドキュメントが腐ってる
7. テストツールがプログラマーにしか使いこなせない
6. 付属テストが動かない、その名はオープンソースと言うんだ
5. テストは高速だけど、実際には何もしてない
4. 誰もオレオレassert関数が理解できない
3. テストツールがPython 3でしか動かない
2. 得体の知れないmockライブラリだ
1. WebテストツールなのにJavaScriptをサポートしてない

少しお酒が入っていたのもあり、ユーモアを交えたおもしろい発表が多かったです。聴衆が発表者を野次ったり茶化したりして会場を盛り上げていました。そういった楽しい場を自分たちで作るという雰囲気が良かったです。BOFは19時から始まり、終わったのは23時をまわっていました。

Lightning Talks：ライトニングトークス

ライトニングトークスは、カンファレンスがある10日と11日の2日間、朝と夕方の4回に分け、多くの時間が取られていました。申し込みは、カンファレンス期間中に早い者勝ちで登録します。すべてのトークを聞いたわけではありませんが、いくつか紹介します。

Local Python Community：ローカル Pythonコミュニティ

印象に残っているのが、（⁠本当の）ガラパゴス諸島でのDjango/Web開発の紹介でした。発表者のSam Clarke（@darwin_bio）は、2名の開発者とCharles Darwin Foundationで働いているそうです。ネットワークはダイヤルアップ接続で、電源はしょっちゅう落ちるとか。そのビデオがA Django/Python solution in an isolated settingです。

他にもPyCon DE 2012やEuroSciPy 2012の発表を見かけました。ライトニングトークスでローカルのPythonコミュニティの発表をするのも良さそうに思えました。いつか日本のPythonコミュニティの紹介もしてみたいです。

Django Python 3 Support：DjangoのPython 3対応

EuroPythonと比較すると、USでのPyConの方がDjangoの話題が多かったです。Testing BOFのライトニングトークスの発表にもDjangoをネタにしたり、“You mean Django?”（お前はDjango信者か？）と茶化して笑いをとる場面が多かったです。

Djangoのリリースマネージャーを務めるJamesのライトニングトークスの中で2012年秋リリース予定のDjango 1.5でPython 3（3.3）を試験的に対応するという発表がありました。会場から拍手が起こっていたのでその人気振りが伺えました。Django’s future、and Python 3からそのトークへのリンクを辿れます。

筆者の周りにはDjango嫌いな方も何人かいますが、好き嫌いが分かれるというのは良いプロダクトだと個人的に思います。

Sprint：スプリント

スプリントは、同じホテルで10個の部屋を設けていました。筆者は2日間だけ参加しました。

Distutils2/packagingスプリント

1日目はDistutils2/packagingに参加しました。Python 3.3で標準ライブラリとして提供されるpackagingをPython 2.x系やPython 3.2以下で使うためのパッケージ名がDistutils2です。同じ部屋ではpip、cheeseshop（PyPI）のスプリントも行われていました。

Distutils2のドキュメントやイシュートラッカーに目を通しながら、バグ修正をやってみようと簡単なバグを探してみましたが、既にパッチが投稿されていて、簡単そうなバグは見つけられませんでした。ざっと目を通した感じでは、Windows系のバグと仕様改善や機能拡張といったイシューが多かったように思います。このスプリント主催者の1人であるTarekのPackaging Sprint/Bof Reportも参考にしてください。

pytestプラグイン開発

2日目はpytestのプラグイン開発をしていました。pytestの作者であるHolger Krekelがすぐ近くにいたので、開発しながらその都度レビューしてもらい、とても嬉しい体験をしました。

ランダムにデータを生成する機能を作りたいと相談すると、pytest_generate_tests()でテスト関数とその引数をフックするサンプルコードを書いてくれました。そのコードを参考にして開発を始めました。

サンプル実装で一通り動くようになり、プラグインとして独立したパッケージにするにはどうしたら良いか？ と相談するとカスタムマーカーが良いと教えてくれました。さらにtmpdirやpytest.mark.parametrize()との共存も必要であることを指摘されて修正しました。

最終的な成果物がpytest-quickcheckプラグインです。

Holgerは、pytest初心者の筆者にも親切に教えてくれて、他にもたくさんの開発者の相談にのっていました。

あとがき・謝辞

海外のPyConに興味をもたれた方は、ヨーロッパで開催されるPythonカンファレンスEuroPythonに参加したときの記事「そうだ！ EuroPython 2011へ行こう」も参考にしてください。また、日本においても9月にPyCon JPの開催が予定されています。

筆者は、OSSと出会い、世界中の開発者とやり取りする機会が身近になりました。いろんな国の、様々な開発者が、それぞれの目的で開発プロジェクトに取り組みます。そこにはその国や地域に根付いた風土や文化もあります。そんな彼／彼女らに接してみることにもおもしろさを感じていたりします。

カンファレンスを通してお世話になった方々がいます。この場を借りて皆さんにお礼を申し上げます。

岩下さん（@tamaxyo）は、CMUに留学されていて、現地で出会った日本人参加者です。Python歴3日でPyConに来られ異文化コミュニケーションを楽しまれたようです。本稿で紹介している写真もたくさん提供していただいて、レビューも手伝ってくれました。

Brian Dorsey（@briandorsey）は、シアトルのPythonユーザーグループの主催者です。以前、日本に来られた際にPython mini Hack-a-thonに参加され、そのときに知り合いました。現地で再会して、とても親切に接してくれました。Testing BOFやHolger Krekelとの出会いは、彼の紹介によるものです。

Ian Lewis（@IanMLewis）は、日本から一緒に参加した友だちです。ホテルを予約してくれて同じ部屋に泊まりました。彼は日本語がとても上手ですが、アメリカなので筆者は英語で会話するようにしていました（英語で表現できないときは日本語で話していましたが…⁠）⁠。これを機に日本でも英語で会話しようかと画策中です。

また、本稿のレビューを手伝って頂いた、寺田さん（@terapyon⁠）⁠、たかのりさん（@takanory⁠）⁠、清水川さん（@shimizukawa⁠）⁠、小宮さん（@tk0miya⁠）⁠、池さん（@rokujyouhitoma）に感謝します。