Make組ブログ

Python、Webアプリや製品・サービス開発についてhirokikyが書きます。

雑談: AIは牛乳を注ぐ女の夢を見るか?

雑談です。

AIは牛乳を注ぐ女の夢を見るのか? 牛乳を注ぐ女というのはフェルメールのあの絵のことです。

ja.wikipedia.org

今の世の中はAI、ディープラーニングの話題がホットです。 ですが今言われるAIはとどのつまり機械学習で、僕が学生のときは「弱いAI」と呼ばれてたように思います。 「AI」なんて言おうものなら鼻で笑われていたので、あえて「集合知」のような言い方をしていたような覚えもあります。

機械学習は十二分にすごいものですが、結局のところは人間にはなれていないなと思います。 人間は、何かを判断するときにも日々の風景や、過去の習慣や常識、昨日食べたステーキの味も参考にして判断しています。 ステーキの味と株価の予測が関係するかは定かではありませんが、その店の中で見た若者の多さとか、店の値段設定から外食産業への投資判断を行ったりはありえます。 要するに、機械学習には感性というか、全く関係がないことを結びつけて考える能力がないわけです (AIさんがランチに出かける日が来るまでは)。

ですが逆に機械学習が今後ももっと発達すると考えると、人類は「強いAI」を求めなくなると思います。 「弱いAI」的な判断や考え方が中心になって、人間的な判断や会話が二の次と考えられるようになると思います。

そういう時代が来るだろうからこそ僕は人間的な感性や、数値に出ないデータが大事だと思います。 なぜなら、人間というのは結局のとこ人間を相手にするものだからです。 どれだけ機械学習や最適化をしても、それは限られた軸の中での世界の話です。 人間の感性を相手に世界が回っている以上、究極は人間の感性にしかできないことがあると思います (少なくとも人間の感性や時代背景、共感性をすべて学習したAIさんが登場するまでは)。

人間の感性的な部分、RX-8に乗って最高のドライブフィーリングを味わう感覚や、アンドロイドは電気羊の夢を見るか?のワクワクや、PH5の光やタリアセンライトにうっとりする感覚や、牛乳を注ぐ女をみて感じるものや、ジムノペディを聴いたりWelcome To The Jungleを聴いて感嘆することが大事なんだと思います。その喜びを知ってるからこそ全く関係ないように思える日々の仕事が素晴らしいものになり、人類にとっての価値が産まれると僕は思っています (機械学習があったとして当時ジムノペディは絶対に作れないと思います)。

ほんとに、フェルメール展に行くのを忘れてたのを後悔してます。 それが言いたかっただけです。

Djangoのresponse.set_cookieはmax_ageを指定すればexpiresが勝手に計算される

DjangoCookieを設定するときは response.set_cookie を使います。

response = TemplateResponse(...)
response.set_cookie("key", "value", max_age=3600)

今まで知らずに expires も自分で計算して設定していましたが、 max_age を指定して expires を指定しない場合は勝手に設定されるので不要みたいです。

DjangoのHttpResponseBaseのset_cookieにこういう実装がありました(Django 2.1で確認)。

        if max_age is not None:
            self.cookies[key]['max-age'] = max_age
            # IE requires expires, so set it if hasn't been already.
            if not expires:
                self.cookies[key]['expires'] = http_date(time.time() + max_age)

django/response.py at 2.1.7 · django/django · GitHub

なので、わざわざこういう関数を作る必要はないです。

from datetime import timedelta

from django.utils import timezone


def set_cookie(response, key, value, max_age):
    expires_at = timezone.now() + timedelta(seconds=max_age)
    expires = datetime.strftime(expires_at, "%a, %d-%b-%Y %H:%M:%S GMT")
    response.set_cookie(key, value, max_age=max_age, expires=expires)

ちゃんと実装を調べてよかった。

PythonとRubyの比較をよく聞かれるので明示するか略せるかが違うよという説明をまとめておいた

よくプログラミング初心者の方に「PythonRubyの違いを教えてください」と聞かれるので書いておきます。

免責

あくまで僕がプログラミング初心者さんに説明するときにこの説明を使うよという視点です。読んでる方が思う視点とか別の意見はぜひご自身のブログに書いてください(読みますので)。 違いはたくさんありますが、5分で簡潔に伝わる違いを伝えたいと思っています。 あと私はPythonをずっと10年近く使っていますが、Rubyはちょっとだけです。でもRubyもとても良い言語だと思っています。

(コードサンプルの色味が読みにくくてごめんなさい。気が向いたら直しときます)

本文

プログラミング初心者に簡単にPythonRubyの違いを説明する場合ベストは「Pythonはより明示します。Rubyはより略せます」だと思っています (あくまでプログラミング初心者に5分以内に伝えると考えたときの視点ですよ)。

細かな違いはあれど、個人的には言語としてPythonRubyではそれほど大きな違いはないと思います (少なくともHaskelとPythonや、ErlangPythonのような違いはないですよね)。

もちろん今回は言語の話です。コミュニティの色や存在しているフレームワーク、ライブラリーの違いは大きくあると思います。 機械学習やデータ処理をしたいなぁ、しかもWebでも同じ言語を使いたいなぁというのであればPythonをオススメします。 でもそういう場合は言語仕様関係なく選びますよね。

言語として「PythonRubyの違いが知りたい」と言うプログラミング初心者の人に分かりやすく違いを説明するのであれば、やはり「明示するか略すか」が良いと思います。

Pythonの明示姓

言うよりも見るということで、フィボナッチ数列の計算をキャッシュありで行うプログラムを2つ書きました。

Pythonの例:

fib = {}
fib[1] = 1
fib[2] = 1


def fibonacci(num):
    if num in fib:
        return fib[num]

    fib[num] = fibonacci(num-1) + fibonacci(num-2)
    return fib[num]


print(fibonacci(100))

Rubyの例:

@fib = {}
@fib[1] = 1
@fib[2] = 1

def fibonacci(num)
  @fib[num] ||= fibonacci(num-1) + fibonacci(num-2)
end

p fibonacci(100)

この2つの例はかなりPythonらしさとRubyらしさを表していると思います。 (もちろんRubyでもPythonのような書き方はできますが、Rubyで書くのであればこの書き方のほうが美しいと思います)

この違いを産んでいるのはこの辺の違いからでしょうか:

  • return の略
  • nil の扱い
  • 代入の違い
  • 例外の違い

Ruby||= でうまく書けると気持ちいい。 Pythonは愚直ですが、何やっているかはパット見で分かりやすいなぁと感じます。

クラスで紹介する他の例

他の例として、Pythonのほうがより明示的に書く必要があるという説明をします。 Rubyでは def メソッド名=(...)@属性名 と記号で書けるところを、Pythonでは明示的に self. などを書く必要があります。

説明用のプログラムでは、PythonRubyAccount クラスを作っています。 Accountfullname というゲッターとセッターを持っており、 fullname という属性に値をそのまま保存します。

Pythonの例:

class Account:
    @property
    def fullname(self):
        return self.fullname

    @fullname.setter
    def set_fullname(self, fullname):
        self.fullname = fullname


user = Account()
user.fullname = "Hiroki Kiyohara"
print(user.fullname)

Rubyの例:

class Account
  def fullname
    @fullname
  end

  def fullname=(fullname)
    @fullname = fullname
  end
end


user = Account.new()
user.fullname = "Hiroki Kiyohara"
p user.fullname

この例は極端に分かりやすい例なので、「見た目Rubyのほうが良いじゃん」と思われるかもしれません。 ですが、Pythonはより「明示的に」書く必要があり、記号や略記が少ないのが特徴です。

Pythonは美しいと僕も思いますが、結構、言語開発者とか深い仕様レベルでの美しさだなぁと思います。実にパースしやすそうです。 パッと見た感じはRubyのほうが小奇麗だと思います。Rubyの言語の深い部分は知らないです。

Slackにて話してると

shimizukawa [11:41 AM]
Rubyは言語仕様が美しくなるように言語設計している
Pythonは文法のパースがシンプルになるように言語設計している

わかり哲也。

僕はそういう意味で、Pythonが好きです。

他のオススメ記事

blog.hirokiky.org

Python3.8のPEP572 (Assignment Expression) とリスト内包表記でフィボナッチ数列を作って遊んだ記録

あつおさんがPEP572でフィボナッチ数列を作って遊んでいたので、僕も遊んでみた。

Python 3.8.0a1時点の話です。

我ながら [(p2 := (p1 + (p1:=p2))) for _ in ...] はよく出来てるなと思った。 あと、PEP572のnamed assignmentは使ってみると意外と制限があるので、思ったよりも良いなと思った。

ただこの動きは直感的にはビックリした。

>>> a = 1
>>> b = 2
>>> a + (a := b)
3
>>> a
2
>>> b
2

あつおさんのブログも見てね

atsuoishimoto.hatenablog.com

aiohttp.ClientSessionのリクエストをaioresponsesでモックする。特定のホストへのアクセスは許可する

aiohttp.ClientSession() でのアクセスをテスト時にモックしたいときに、 aioresponses というライブラリーが使えます。

github.com

Pythonのrequestsライブラリーを簡単にモックできる responses というライブラリーがあるのですが、そのresponses-likeに使えれて便利です。

from aioresponses import aioresponses


def test():
    with aioresponses() as mocked:
        moked.get('http://foobar/api', payload={...})

       call_function_under_test()

特定のホストへのアクセスは許可する

この aioresponses 、良いのですがデフォルトで全てのリクエストをモックするようです (0.5.2時点) 。 問題としては例えば、 aiohttp でサーバーのテストを書いているとき、そのテストサーバーへのアクセスなどもモックして動作しなくなることです。

そこで、以下のようなpytestのフィクスチャーを書いておくと便利です。 ここでは pytest-aiohttp をインストールしている前提です。

@pytest.fixture
def responses(cli):
    base = cli.make_url('/')
    with aioresponses(passthrough=[str(base), ...]) as mocked:
        yield mocked

この例では、テストサーバーのホスト(上記の base 変数の値)へのアクセスを許可しています。 バックエンドのミドルウェアを通してテストする場合などは、 'unix://' なども許可しておくと良いです。

基本的に全てのアクセスは許可しておいて mock.get(...) のように追加したURLだけモックするようにしたい気はします。

ともあれ、aiohttp.ClientSessionを使うと aioresponses を使うと便利です。

pytest-asyncioとpytest-aiohttpを一緒に使うとRuntimeError got Future attached to a different loopがでる

pytest-asynciopytest-aiohttp を同時に使うと、テストの中で使うイベントループが別のものになってしまってエラーが出ます。

RuntimeError: Task <Task pending coro=<...> cb=[...]> got Future <Future pending> attached to a different loop

github.com

github.com

aiohttpを使ってるWebアプリのテストを書くときは pytest-aiohttp に寄せたほうが良さそうです。 pytest-aiohttp を使えば loop のフィクスチャーで、テストで使うイベントループが取れるのでそれに寄せるようにします。

github.com

asyncioとpytestでテスト用fixtureを作るときにgot Future <Future pending> attached to a different loopが出る話

Pythonでasyncioを使うアプリケーションのテストを書くとき、event loopに気を遣ってあげないとエラーになるという話です (今回はaiohttpを使ってWebアプリを作っているときに起こりました)。

こんなエラーがでました。

RuntimeError: Task <Task pending coro=<...> cb=[...]> got Future <Future pending> attached to a different loop

テスト側で動かすイベントループと、アプリ側が動かそうとする、イベントループに違いがあると発生してしまいます。 例えばアプリ側で何らかのバックエンドにアクセスするクライアントを使っていて、テスト側でもデータ(フィクスチャー)を作ったりクリーンアップしたいとします。 そのときに双方の使うクライアントが内部で使っているイベントループが違うものだと上記のエラーが発生します。

テスト用の pytest-asyncio などのライブラリーが、テスト用のイベントループを用意する場合は、アプリ側でクライアントを起動時にモジュールグローバルに保存しないようにしておきます。 そのクライアントがインスタンス化されるときに、内部で asyncio.get_event_loop を呼ぶことがあるからです。 もしくはテスト時にクライアントを差し替えるようにします。

この例だと pytest-asyncioevent_loop フィクスチャーを取っておくことでテスト用のイベントループを有効にしておきます。

import pytest

import somebackend


@pytest.fixture
async def somebackend(event_loop):
    client = somebackend.Client()
    try:
        yield client
    finally:
        do_cleanup_here()

テストでは以下のように使えます。

@pytest.mark.asyncio
async def test_foo(somebackend):
    await somebackend.create("some thing")

    actual = await call_function_under_test()

    assert actual == "expected"

今回は aiodocker を使っていて起こりました。

この情報が何かの参考になれば嬉しいです。 また、asyncioやイベントループ周りについて詳しければ教えてください。

近そうな話

github.com