matobaの備忘録

育児しながら働くあるエンジニアの記録

Type Hintを触ってみよう

下書きにメモを供養します。

PythonでTypeHint導入の足がかりを探す話です。

こんにちは。 Pythonを仕事で書いてますが、少なくとも僕はTypeHint(typing)は使ってません。 そもそも、TypeHintという呼び方があってるのかもわかりまん。ていうか、ほとんど書いたこともありません。 ただ、周りで使ってる風の話を聞くことが増えてきたり、気になってはいます。 最近、「あっ、ここで使うと便利なのかも?」って思った時があり、それについての理解を整理したくなったのでこの記事を書いてます。

きっかけの一つ

そもそも、TypeHintを使ってみようかな、と思った一番のきっかけは、TypeScriptに関する次の記事を見たことです。

私の拙い理解によると、TypeScriptはJavaScriptに型ヒントを与えて、静的解析可能にするものです。 typingもPythonに型ヒントを与え、mypyで静的解析可能にするものであり、同じ役割になると理解してます。(今のところ)

で、見た記事というのはこちらです。

https://gist.github.com/mizchi/9e71569f72187af749adfecea49fb38a

上記のURLはとある発表の資料とのことですが、目的は次の二つだそうです。

  • TypeScript を導入しない言い訳を全部潰す
  • そのために痛みがない導入・運用を提示する

いやー、PythonでType Hintを入れない言い訳をどんどん潰してくれそうでありがたいなと思いました。

というわけで詳しく読んで気になる話を書いていきます。

型付けにはコスパ感覚がある

上記のURLの中で印象的だったのはTypeScriptで型をつけるときのコスパの話です。

上記の記事の中で、型をつけるコスパがいい部分とよくない部分があるという話が書いてあります。

いやーーーーー!!めっちゃありそう!!! 全然、経験ないけど、コスパ悪い型づけとかありそうーーーーー!!!

https://gist.github.com/mizchi/9e71569f72187af749adfecea49fb38a#%E5%9E%8B%E3%81%AE%E3%82%B3%E3%82%B9%E3%83%91%E6%84%9F%E8%A6%9A

その中でもViewの入力とかViewのステートとかの型はコスパ悪い、って話を書いてて、めっちゃありそうと思った。

フレームワークに乗ってたら自明な型は後回しでよくね?

例えば、Djangoフレームワークを使っていて、とあるアプリの中にviews.pyがあったとする。 そして、そのviews.pyの中に例えば top_page_view という関数があったとしよう。

from django.http import HttpResponse

def top_page_view(request):
    return HttpResponse("top page view")

これに対して、type hintをつけるならこんな感じだろうか。

from django.http import HttpRequest, HttpResponse

def top_page_view(request: HttpRequest) -> HttpResponse:
    return HttpResponse("top page view")

これはコスパが悪い。なぜかというとDjangoフレームワークを使ってる時点で、views.pyの中にある関数は基本的にview関数だろうし、view関数に渡ってくるのは、HttpRequestだし、返すのはHttpResponseだから。

typingを書くことによって、コードの読み手が得られる情報が全然増えていない。 ただ単に、読むコード量が増えただけ。

以下のような類のコメントと同じでない方がいいような気もする。

from django.http import HttpResponse

# トップページのビュー
def top_page_view(request):
    return HttpResponse("top page view")

確かに型をつけた方が安心だというのはわかるけど、型をつけるというのは手足に重りをつけて動くような気がするんですよね。

終わり

めんどくさくなって来たのでここで終わります