このBlogは移転しました。今後は aish.dev を御覧ください。

めんどくさいmock.patch()

unittest.mock モジュールを正しく使って関数を置き換えるというのは以外と難しいもので、Python名前空間について、しっかり把握できてないとうまくいかないことがある。

単純なケースでは、テスト対象のコードが参照している名前で置き換えてやればいい。 例えば

import spam

def ham():
    spam.egg()

というモジュール Mham() をテストするために spam.egg を置き換えるなら

def test():
    import M
    with patch("spam.egg"):
        M.ham()

となる。また、

from spam import egg

def ham():
    egg()

のように egg を参照している場合、ham() の内部での eggM.egg への参照なので

def test():
    import M
    with patch("M.egg"):
        M. ham()

となる。

ここで注意しなければならないのが、関数を置き換える対象となるモジュールは、関数を呼び出すときに指定するモジュールではなく、関数が定義されたモジュールだということだ。

例えばもう一つのモジュール、M2 があって、

import M
ham2 = M.ham

となっている場合がある。こんな場合でも、M2.ham2() で呼び出される egg() を置き換えるには

def test():
    import M2
    with patch("M.egg"):
        M2.ham2()

のように、ham を定義したモジュール Megg を置き換えなければならない。

このように、機械的に mock.patch() を使って置き換えることはできず、置き換える対象の関数がどのように呼び出されているか、ちゃんと調べてなくてはならない。普通はあまり気にしなくても良いのだが、たまに変な import などでどのモジュールを使っているのか調べにくいパッケージなどもある。そういう時は、

@contextlib.contextmanager
def patch_globalref(func, target):
   m = MagicMock()
      with patch.dict(sys.modules[func.__module__].__dict__, **{target:m}):
             yield m

のような関数を用意しておいて、

def test():
    import M2
    with patch_globalref(M2.ham2, 'egg'):
       M2.ham2()

とように、テスト対象の関数オブジェクトのグローバルスコープを直接修正してしまうほうが手っ取り早い場合もある。

ジェネレータの循環参照

以前、ジェネレータが循環参照の一部になっている場合、メモリが開放されなくなるケースがあるという エントリ を書いた。

最近、この仕様が 問題となっていた ようで対策が検討されていたが、ついにトランクにコミットされたようだ。

http://bugs.python.org/issue17807

従来のジェネレータでは、ジェネレータオブジェクトへの参照が全て破棄されて不要となった時に GeneratorExit 例外を送出してコードの実行を再開し、ジェネレータ内の finally 節が実行されるようになっていた。Pythonのコードで書くと、こんな感じになる

class Generator:
   def __del__(self):
      if self.generator:
         self.generator.send(GeneratorExit)

ここで、ジェネレータオブジェクトは __del__ メソッドを持っているため、このオブジェクトが循環参照の一部となっていた場合、ガベージコレクションでは開放できない、というのが上のエントリの話だった。

Python3.4では、上のコードの __del__() メソッドに相当する部分が削除され、代わりに ジェネレータ を実行中のフレームオブジェクトを開放するときに終了処理が起動されるようになった。このため、ジェネレータオブジェクトが循環参照に巻き込まれても、オブジェクトは保存されずに開放されるようになった。

終了処理をジェネレータからフレームに移すとなんで循環参照の問題が解決するのか不思議だったが、パッチを見ると、終了処理が必要なジェネレータでも、リファレンスカウントがゼロになったら無慈悲に削除してしまうようだ。フレームオブジェクトの開放処理を見ると、実行中のコードオブジェクトとそのフレームオブジェクトだけ使って、フレーム開放時にジェネレータの finally 節を実行できてしまうのだ。ジェネレータの後始末をするのにジェネレータ自体は不要だったというのは実に面白い。

ということで、このまま問題がなければ、Pytho 3.4からは安心してジェネレータをあっちこっちから参照できるようになったわけだ。もちろん、フレームオブジェクトを下手に使うとやはり循環参照になってしまうが、これはジェネレータだけの話ではないし、うかつに sys._getframe() を使ってフレームをどっかに保存するようなヤカラは、ひどい目にあえばいい気味というものである。

日本語でreStructuredText

実のところ、私はあんまり reStructuredText /Shinx が好きではない。Markdown と比べるとシンプルさで劣り、TeXと比べると印字品質で劣る。この辺の中途半端さが、restを愛せない大きな理由だが、もう一点、日本語の文章を書くのに適切なマークアップ言語ではない、というのも大きい。英語などの、単語と単語の間にスペースがある言語向けに設定されており、日本語で書こうとするとイライラが溜まってどうしょうもないのだ。

とはいえ、SphinxPythonの公式ドキュメントで使われているツールでもあり、ちょっと複雑なドキュメントを書くには Pandoc を使うよりは便利なことも多いので、ある程度は使えるようにしてみたい。ということで、私が使っていて一番イライラする、インラインマークアップの改善に取り組んでみた。

通常のrestでは、インラインマークアップの前後に空白や区切り文字が必要なため、

restは*うざい*!

とは書けない。

restは\ *うざい*\ !

などと書かなければならない。実にうざいので、スペース無しでもマークアップとして認識できるようにしてみた。

https://sourceforge.net/p/docutils/patches/103/

このパッチでは、前後のスペースや区切り文字などのチェックをいっさいチェックせず、`*` などの記号は全てマークアップとなる --no-inline-delimiters オプションを追加している。

$ rst2html.py --no-inline-delimiters sample.rst 

ディレクティブでも指定できる。

.. no-inline-delimiters yes

ここでは*普通に*マークアップを書ける

.. no-inline-delimiters no

ここでは\ *書けない*\ !

この方式で日本語環境でも使いやすくなったのではないかと思うが、どうだろうか?現在わかっている問題点として、アンダーラインを含んだ英単語がマークアップとして認識されてしまう、という点がある。

mod_wsgi

とすると、これは mod へのリンクと解釈されてしまうので

mod\_wsgi

と書かなければならない。許容範囲といえば許容範囲な気もするが、できれば治したい気もする。他にもなにか落とし穴があるかもしれない。気がついた点があれば、こちら で議論に参加していただきたい。

知らなかったが、Docutilsの開発者 David Goodger さんの奥様は日本人だそうで、Davidさんも日本語の知識がおありだそうだ。このパッチについても前向きに検討して頂いてる雰囲気なので、興味や意見があれば、ぜひともご協力いただきたい。

PowerPointは僕らのIllustratorだ

普段、図を書いたりすることはそれほどないが、書くときは適当にPowerPointを使って書いてしまうことが多い。このページの図 なんかもPowerPoint製で、けっこう綺麗な図を手軽にかけるので重宝している。

書くのが簡単なのはいいんだけど、書いたあと、画像として出力するのが微妙にめんどくさい。数が多いとうんざりする。ということで、Sphinxの文書を書くときのために、PowerPointのプレゼンテーションから画像を抽出し、png ファイルとして保存するDirectiveを作成してみた。

この拡張は標準の image ディレクティブのパラメータに加え、pptfilenameshapename を指定できる。

.. ppt-shape:: abc.png
   :pptfilename: testppt.pptx
   :shapename: shape-title

pptfilename には、PowerPointプレゼンテーションのファイル名を指定し、shapename には、図形の名前(図形の書式設定|代替テキスト|タイトル で指定した、図形のタイトル) を指定する。Sphinxで文書をビルドする時、プレゼンテーションが更新されている場合は画像を抽出してファイルに保存する。PowerPointがインストールされていない環境では、作成済みの画像をそのまま使用する。

動作環境

インストール

$ git clone git://github.com/atsuoishimoto/pptshape.git
$ cd pptshape
$ python3 setup.py install

使い方

  1. Sphinx の設定ファイル conf.py の、extentions を次のように修正する。
extensions = ['pptshape.directive']
  1. プレゼンテーションの画像は、複数の図形から構成される画像の場合はグループ化して一つの図形に変換し、図形の書式設定で 代替テキスト|タイトル に、画像の名前を指定する。
  2. rst ファイルに、次のディレクティブを記述する。
.. ppt-shape:: abc.png
   :pptfilename: testppt.pptx
   :shapename: shape-title

ppt-shapeディレクティブは、Imageディレクティブと同じ機能をサポートしており、PowerPointがインストールされていない環境(Unix,Macなどを含む)では、Imageディレクティブとまったく同じ動作となる。

ppt-shapeは pptfilename で指定したプレゼンテーションから、shapename というタイトルの画像を検索し、引数として指定した画像ファイルとして出力する。文書のコンパイル時、プレゼンテーションファイルと画像ファイルの更新日付をチェックし、更新された画像ファイルだけを生成する。

動的型言語の使いどころ - その2

先日、動的言語の使いどころ という記事を公開してしまった。公開して「しまった」というのは、じつはあの記事はもうしばらく寝かしてから公開するつもりで、まだ未完成だったためだ。なんで公開するつもりがないエントリが公開されてしまったかというと、エントリを更新してリポジトリにpushすると自動的にサイトが更新されるからくりを仕込んだのをすっかり忘れて、気軽に git push してしまったのだ。ということで、前のエントリで書いておきたかったことをもうちょっと書き足しておきたい。

私は Python を使ってはいるが、それでも、Python 使うやつとか馬鹿じゃねーの、と思うこともそれほど珍しくはない。特に、自分で Python を使うのと、他人が書いた Python アプリケーションを使うのはまったく別の話で、他人に対しては「Python 使うなよ」と言いたくなってしまう時もないではないのだ。

例えば、有名な Python製チケット管理アプリケーションの Trac というのがある。ここ数年は Trac を使っていないが、以前使っていた時には、Trac を管理するのがイヤでイヤで仕方がなかった。Trac は本体は比較的シンプルな機能しか持たず、いろんなプラグインで機能を拡張して便利に使えるタイプのアプリケーションだが、 本体のバージョンアップにプラグインがきちんと追随できていないことが多く、迂闊にバージョンアップしてしまうとあれが動くがこれが動かない、バージョンアップしなくてもこっちのプラグインが旧バージョンでは動かなくなってしまう等々の問題が頻出するのだ。

こういうのは、Javaなんかで書いてあるアプリケーションなら比較的対処しやすい。本体の仕様変更などはプラグインに配慮してそれほど大胆な変更はしないもので、非互換な点があってもとりあえずコンパイルしてエラーが出た部分をちょこっと直してやれば、大概はそれで済む。

しかし、これがPython製だとそうも行かない。動かしてみないことにはどこにエラーが有るかわからないし、テストしようにも、そもそもテストスクリプトがあるのか、あったとしてもどうやって起動するのか、環境をどうやって作るのかというのをいちいち調べなければならない。運良くテストを実行できて問題を検出できたとしても、これを直すのがまた一苦労だ。アプリケーションとプラグインのコードベースをよく知っているならともかく、そうでなければ、どこがどう変更されているのか、GrepやらVCSのログやらを頼りに探しまわらなければならない。これは Python/Tracに限った話ではなく、例えばFirefoxのアドオンがちょっとしたバージョンアップで無効化されてしまったり、VimEmacsの拡張が使えなくなってしまったりということはよくあることだろう。

では、TracJavaで書きなおすべきなのかというと、そうも言い切れない。ダックタイピングの手軽さで、JavaC++ だとプラグインの更新やリビルドが必要となってしまうようなケースでも、Pythonなら修正不要でそのまま使えたりするし、そもそも互換性が問題になるほどたくさんのプラグインが書かれているのは Python で気軽に書けるというのも大きな要因で、これが全部 Java で書かなきゃならんとなったら、こんなに人気が出たかどうかはわからないだろう。

きっと、Tracのようなアプリケーションでは、PyPIなどのリポジトリとの連携、Jenkinsまでは行かないまでも、単純なAPIのバージョンチェックにとどまらない、簡単なテスト実行方法の標準化といった、ソフトウエアのライフサイクル全体への配慮がもっと必要なんだろう。これは別に動的言語に限らず必要ではあるが、Pythonのように手軽に使えることを期待されてしまうプログラミング言語を使うのであれば、その特徴をもっと生かしたアプリケーション作りが要求されるのだと思う。

動的型言語の使いどころ

型宣言というのは良い物だ。型が明確なら、実行速度は型情報がない場合と比べて100倍も200倍も高速になるし、エラーチェックだってできる。リファクタリングも簡単だ。

型がないほうがいいという人は、昔の、まだプロトタイプ宣言がなかった頃のCコンパイラでも使ってみるといい。静的型チェックの有り難みが身にしみることだろう。型宣言を書くのがめんどくさいったって、大したことはない。さすがにC++の型宣言はめんどくさかったが、autodecltype のおかげで楽になった。それでもめんどくさいというなら、Fortranでも使って i ではじまる変数名は宣言不要とか言って喜んでるといい。「暗黒の型宣言」とか言い換えて中二病気分を満喫するのもいいだろう。

しかし、動的な型システムの言語というのも、それはそれで良い物だ。現在、私の主力言語はPythonであり、そのメリットは日々実感している。動的型システムを使った開発スタイルのほうが、静的型システムを使った開発スタイルよりも私の目的には適しているからだ。

アプリケーション開発という面から見た時の、動的型言語のメリットとはなんだろうか。色々とあるが、システム開発全体のライフサイクルへ与える影響を考えると、「不具合のあるアプリケーションを実行できる」ということだと思っている。「そんなアプリ実行しねーよ」と思うかもしれないが、そんなことはない。開発中・修正中のアプリは全て不具合のあるアプリで、この期間中、我々はアプリをだましだまし実行しながら開発・デバッグを進めているのだ。動的型言語をつかうなら、この「だましだまし」のだましやすさを意識し、最大限に活用しなければ意味が無い。

昔からよく言われるプログラミングの格言に、こんなのがある -

「Make it work, Make it right, Make it fast - in that order.」

とりあえずでも何でも、まずはなによりも動くコードを書き、次にそのコードが正しく動くようにする。最後に、パフォーマンス上の問題があれば、適正な時間内に処理できるようにする。「動かす・正しく・速く」と、この順番が重要だ。正しい処理があいまいなうちにコードを最適化しても意味が無いし、正しくないコードでも、動かないコードよりははるかにマシだからだ。

動的型言語は、このスタイルの開発に素晴らしくマッチする。書きやすいところ、書きたいところ、気になってるところなどを気ままに書き散らし、実行して思考内容を実験できる。「Make it work」のステップを、段違いに素早くすすめられるのだ。このメリットを活かせば、ものすごいスピードで実装と実行を繰り返してアプリケーションドメインと問題点を正しく理解し、最終的には「正しい」実装にまでたどり着ける。開発手法としては、トップダウンというよりボトムアップなアプローチに適しているだろう。

もちろん、デメリットもある。「Make it work」が効率的でも、「Make it right」のステップでは不利な面もある。静的型システムならコンパイル時に検出できるエラーもでも、動的型システムだと動かしてみないとわからない。しかし、このような型チェックで検出できるのは、かなり単純なエラーだけで、単純な関数の引数間違いなど、うっかり見逃して本番環境で出してしまうと、背中が汗でびしょびしょになるようなやつだけだ。こういったエラーは単体テストを流すだけでほとんど検出できるし、動的言語ではテストを書くコストが安くつくので、単体テストカバレッジ100%近くを目指すのもそんなに難しいわけではない。動的型言語でも静的型言語でもテストを書く必要性は変わらないわけで、ここは大きな問題ではないと考えている。

ただ、リファクタリングツールなどでコードの自動修正などを行うのは難しいし、静的にコードを解析してコード補完を行うことも難しい。もしPythonが静的な型システムを持っていたら、Python2->3の移行はあっという間に完了したことだろうw。パフォーマンス面の不利はもちろんあるし、JITを使っても万能ではなく、JITのコストでかえって負荷が増大する場合もある。単純に変数の宣言がないから素晴らしいとか、そんな単純な話ではないのである。