ちょっとしたツールを作るのに便利なPythonライブラリ

この記事は、[LIFULL Advent Calendar 2017](https://qiita.com/advent-calendar/2017/lifull)の2日目の記事です。

おはようございます。新UX開発部の二宮( @ninomiyt )です。

LIFULLではデータ解析や最適化の用途、もしくはAWS Lambda上の簡易ツール実装用途などでPythonがそれなりに普及してきました。数値計算寄りの（いわゆるデータサイエンティスト的な）メンバーも今はPythonを使うことが多く、コード量としては小規模なプロジェクトが多く、簡単なAPIやバッチ処理の実装までやってもらうこともあります。

そのレビューをやっていく中で、「これ使うともっと簡単に実装できるよね」っていうライブラリがいくつかまとまってきたので紹介します。

# click

コマンドラインパーサー用のライブラリで、デコレータを使って関数を簡単にCLI化できます。

標準ライブラリの[argparse](https://docs.python.jp/3/library/argparse.html)がありますが、clickではバリデーションの処理もまとめて行うので、圧倒的に楽になると思います。

* [PyPI](https://pypi.python.org/pypi/click)
* [Document](http://click.pocoo.org/5/)
* [日本語記事](https://dev.classmethod.jp/tool/python-library-click/)


# retry

現実のアプリケーションでは「データの取得に失敗した際に、何度かやり直す」コードを書くことがあると思います。それをデコレータを使って簡単に実現するライブラリです。

* [PyPI](https://pypi.python.org/pypi/retry/)
* [Document](https://github.com/invl/retry)

# requests

httpクライアントを作るためのライブラリです。

Pythonコミュニティ内でも信頼性の高いライブラリとして認識されていて、Pythonの標準ライブラリである[urllibのドキュメント](http://docs.python.jp/2/library/urllib.html)にも「より高水準の HTTP クライアントインターフェイスとしては Requests パッケージ がお奨めです。」と紹介されています。

例えばOauth認証が必要な場合でも[requests-oauthlib](https://pypi.python.org/pypi/requests-oauthlib)などの似たインターフェイスを目指したライブラリが多くあるので、requestsでは実現できない用途でも類似ライブラリでコードをほとんど変えずにカバーできることも多いです。

* [PyPI](https://pypi.python.org/pypi/requests)
* [Document](http://requests-docs-ja.readthedocs.io/en/latest/)

# Cerberus

これは同僚に教えてもらったもので、入力値のバリデーションを行うためのライブラリです。

辞書の中身やリストの長さ、文字列の正規表現のバリデーション等、単なる型のチェックだけでは難しい箇所もできます。

AWS LambdaとDynamoDBを使ってレコメンドAPIを作るプロジェクトがあったのですが、その際の入力値バリデーションをCerberusで行うとかなり楽になりました。下手にテストコードを増やすより開発者もレビュワーも負担が少ないと思います。

* [PyPI](https://pypi.python.org/pypi/Cerberus)
* [Document](http://docs.python-cerberus.org/en/stable/)
* [日本語記事](https://qiita.com/terukizm/items/db8a70158e94525c69d5)

# chalice

Flask/bottle風のコードで、AWS Lambda上にREST APIを作れるライブラリです。

デプロイ時にAPI Gatewayも含めて設定してくれたり、一般のサーバー上でもテスト用途で立ち上げられたり、開発時に便利な機能はひととおり揃っているように思いました。

実は[apex](https://github.com/apex/apex)や[Zappa](https://github.com/Miserlou/Zappa)等の類似のプロジェクトは[いくつかある](https://qiita.com/massa142/items/c59275237979fd939791)のですが、aws公式のライブラリであることや、少なくとも今は他のクラウドサービスに対応する必要がないことからchaliceを使っています。

* [PyPI](https://pypi.python.org/pypi/chalice)
* [Document](http://chalice.readthedocs.io/en/latest/)

# pandas

データ分析用途で便利なライブラリで、（おそらくR言語由来の）「データフレーム」というテーブル形式でデータを扱う機能などを備えています。

SQLによって様々なデータソースからデータ取得できるなど、ETL的な用途でも役に立ちます。

ただ、API（pandas.DataFrameのメソッド）が個人的に使いづらく、例えば[Sparkpy](https://qiita.com/taka4sato/items/4ab2cf9e941599f1c0ca)やR言語の[dplyr/tidyr](https://qiita.com/matsuou1/items/e995da273e3108e2338e)みたいに分かりやすくできないかと悩んでいます。また、大きなデータフレームに対してassignメソッドを使う時に内部でデータフレームの[(deep)copyが行われて](https://github.com/pandas-dev/pandas/blob/v0.20.3/pandas/core/frame.py#L2492)、想定以上にメモリが必要だった例も見ました。

なので個人的には「便利でデファクトスタンダードなんだけど、レビュー/実装のときに不安も多い悩ましいライブラリ」という印象です。

* [PyPI](https://pypi.python.org/pypi/pandas)
* [Document](https://pandas.pydata.org/pandas-docs/stable/)

# まとめ

Pythonには豊富なライブラリがあるため、それらを上手く使えばアルゴリズムの実装に集中する（してもらう）ことができるでしょう。

「こういうライブラリがあれば楽なのに」と思ったときは、[awesome-python](https://github.com/vinta/awesome-python)の該当項目を見た後に[PyPI](https://pypi.python.org/pypi)で検索するだけでも良いライブラリが見つかることが多いです。

また、今のところ小規模なプロジェクトが多いので、どうしても視点が偏っていたり、「他にもこんなライブラリが便利」などの意見もあると思います。そういう方はコメントをください。

最後になりますが、ひきつづきLIFULL Advent Calendarにもご注目頂けると嬉しいです。

* https://qiita.com/advent-calendar/2017/lifull
* https://qiita.com/advent-calendar/2017/lifull2