AREKORE

daikikatsuragawaのアレコレ

Python Kansai #03 with Mix Leap Study #74の振り返り

先日、Python Kansai #03 with Mix Leap Study #74に登壇者として参加してきました。

kansai-python.connpass.com

本記事はその記録です。

Python Kansai #03 with Mix Leap Study #74とは?

Python Kansai #03 with Mix Leap Study #74とは、Python Kansai*1というPythonに関する関西でのコミュニティおよびイベントとMix Leap Study*2というLINEヤフー主催のLINEヤフー大阪オフィス大阪オフィスで開催される勉強会の共催となっています。

以下の日時、場所で開催されました。

  • 日時:2024年4月17日 19時から21時
  • 場所:LINEヤフー株式会社 大阪グランフロントオフィス

個人的には、Python KansaiとMix Leap Studyのどちらも初めての参加でした。関西のPythonを使うエンジニアとしては親和性の高い(と勝手に感じている)イベントになります。また、しばらく関西に住んでいる身としては、グランフロント大阪が会場というのはとても良いと感じますね…

ブラウン(大阪版)

トーク

ありがたいことにスピーカーとして参加させていただき、「Polars入門」というタイトルで発表しました。2024年以降、個人的にPolarsを使い始めたのですが、その決断の経験に基づく「Polars入門」したくなるような話をしました。当日のスライドは公開されているため、気になった方は見ていただけると幸いです。

speakerdeck.com

当日、会場の方々にPandas、Polarsをそれぞれの使用経験を伺いました。目視でざっくりと数え上げた結果は以下でした。

  • Pandasの使用経験がある方:95%
  • Polarsの使用経験がある方(Pandasの使用経験がある方も含む):5%

つまり、Polarsの使用経験がある方がほとんどいなかったです。念の為、運営してくださっていた小川さんのXのポストも添えさせていただきます。

この現状を把握できたのは最も大きな収穫でして、まだまだPolarsの魅力の伝え甲斐があるなと感じられました。このインタラクティブなやり取りができるのはオフラインでの開催の良さですね。

他の方の発表も聞いていたんですが、どなたも基礎というよりは応用的な内容で興味深かったです。

その他

この機会に対する雑多な話を以下に記録しておきます。

資料の作成において、以下のスライドを参考にして、ChatGPTと二人三脚で作成しました。少なくとも目次の作成や初動はとても早くなりますね。

speakerdeck.com

挿絵についてもChatGPTにより、DALL-E 3を使って画像を作成しました。明確な目的を持って使った初めての経験だったので良かったです。ちゃんとそれっぽいものが出力されますね。

当日は緊張もあってかバタバタしてしまい、ステッカーをもらったり、看板の写真を撮れず、ちょっと後悔しています…軽食も用意してあり、とてもありがたかったです。ただ、こちらもバタバタしてしまい、(モラルの範囲内で)十分にいただけなかったなと後悔しています…余裕のある人間になりたい。

資料中にTypoがチラホラあるので、なんとかしたいですね…対策を考えています。

まとめ

そんな様子でPython Kansai #03 with Mix Leap Study #74に参加してきました。運営の方々、本当にありがとうございました。様々な観点で、とても学びの多い機会になりました🙋次回以降のPython KansaiもMix Leap Studyも参加したいと思います。

ノートブックをキレイにするためのTips

「PyCon APAC 2023」のPoster Sessionにおいて発表した「ノートブックをキレイにするためのTips」を記事として書き起こしたものになります。

2023-apac.pycon.jp

ポスターは以下から閲覧が可能です。

speakerdeck.com

概要

Jupyter NotebookやGoogle Colaboratoryなどのノートブックは、データ分析などの目的で使用されるインタラクティブにコードの記述や実行が可能な開発環境です。作成したノードブックを他者や未来の自分が改めて閲覧や実行をする可能性がある場合、実装の意図を伝えるために可読性を高く、意図した振る舞いを担保するために堅牢性を高くすることが大事です。ただし、ノートブックはそれ自体がソフトウェアとして実装されるものではないことから、可読性や堅牢性を向上させるメリットとコストのトレードオフを特に注意する必要があります。本発表では、ノートブックの可読性や堅牢性を向上させる(キレイにする)ために、可能な限りコストをかけずにメリットを得る方法(Tips)を紹介します。ご自身の管理されているノートブックの状況に合わせて、採用を検討してください。

管理コストの低いパラメータの扱い方

調整の可能性があるパラメータは、様々なセルに記述するのではなく、可能な限り少ないセルに集約すると、見通しが良く、管理コストが低くなります。そして、ノートブックの冒頭にあると、さらに見通しが良いです。実行毎に指定する値は、実行者が入力する仕組みにすると、その旨を伝えられます。

パラメータの集約

# 乱数の種
RANDOM_SEED = 2023
# PyCon APAC 2023のセッション数
NUMBER_OF_SESSIONS = 5

実行者が入力する仕組み

email_address = input("Eメールアドレスを入力してください: ")
Eメールアドレスを入力してください: 

コードに残さないセキュアな情報の扱い方

他者への共有が望ましくないパスワードなどのセキュアな情報は、漏洩するリスクから、コードでの管理が望ましくありません。実行者に入力させる仕組みにするか、環境変数として管理をすると、その旨を伝えられます。

実行者が入力する仕組み(入力内容をマスク)

from getpass import getpass
password = getpass("パスワードを入力してください: ")
パスワードを入力してください: 

環境変数として管理

import os
password = os.environ.get("PASSWORD")

意図を伝えるための変数と定数の定義

変数や定数を定義する際は、型ヒントやデータクラスにより、どんな内容を意図しているのかを示すことができます。

型ヒントによる意図の表現

conference_name: str = "PyCon APAC"
conference_year: int = 2023

データクラスによる意図の表現

from dataclasses import dataclass
@dataclass
class Conference:
    name: str
    year: int
conference = Conference(name="PyCon APAC", year=2023)

マジックナンバーの防止

マジックナンバーになり得る値は列挙型で定義をしておくことで、以降のコードにおいてマジックナンバーを防止することができます。

列挙型によるマジックナンバーになり得る値の定義

from enum import Enum, unique
@unique # 重複を防止
class Prefecture(Enum): # ※一部省略
    TOKYO = 13
    OSAKA = 27
print(f"PyCon APAC 2023の開催地:{Prefecture(13).name}")

後続処理への影響を避けるバリデーション

後続処理が期待していない値を検知するために、可能な限り早期にバリデーションをすると良いです。また、データのバリデーションを実現するライブラリであるpydanticを活用することで、パラメータや変数(定数)を容易かつ早期に検知することが可能です。

早期のバリデーション

FIRST_YEAR = 2010
assert conference_year > FIRST_YEAR

早期のバリデーション(pydantic)

from pydantic.dataclasses import dataclass, Field
FIRST_YEAR = 2010
@dataclass
class Conference:
    name: str
    year: int = Field(ge=FIRST_YEAR)
conference = Conference(name="PyCon APAC", year=2023)

関数の振る舞いを伝える簡易なテスト

doctestを使うことで、関数の振る舞い伝える簡易なテストの実現ができます。それに加えて、テストであることによって関数が意図した振る舞いであることを担保できます。

doctestを使った簡易なテスト

def add_year(year):
    '''
    >>> add_year(2023)
    2024
    '''
    return year + 1
import doctest
doctest.run_docstring_examples(add_year, globals())

セル内の冪等性を担保した変数の扱い方

特定のセルを複数回実行した場合であっても、後続処理に意図した値を伝えるために、セル内の冪等性を担保した変数の扱い方をすると良いです。例えば、変数を使いまわさない(変数の再代入をしない)ことが挙げられます。

変数を使いまわさない(変数の再代入をしない)

year = 2023
# year = year + 1
next_year = year + 1 # 冪等
# print(year)
print(next_year) = year + 1 # 冪等

その他

  • テキスト(Markdown)のセルによる説明の追加
  • 適度なセルの分割
  • 適度なファイルへの分割
  • フォーマッターの導入
  • リンターの導入
  • Gitの導入
  • 「すべてのセルを実行」で問題なく実行されることを確認
  • CI(継続的インテグレーション)の導入
  • コードレビューの実施(意図が伝えられていない箇所の洗い出し)
  • 「出力をすべて消去」した上で管理(オプション)

PyCon APAC 2023の振り返り

先日、PyCon APAC 2023にポスターセッションのスピーカーとして参加してきました。

2023-apac.pycon.jp

本記事はその記録です。

カンファレンス感

トーク

当日に会場で、後日にYouTubeで視聴しました。特に印象に残った3選を挙げます。

好きとか嫌いとかはいい、練習してテストを書けるようになるんだ

ftnext.github.io

テストコードの一歩目として非常にオススメです

引用:好きとか嫌いとかはいい、練習してテストを書けるようになるんだ

自分の発表でも言及していたのですが、低コストで導入できる「better than nothing」な打ち手として、doctestがオススメなんですよね・・・

docs.python.org

Pythonで スナップショットテスト

speakerdeck.com

スナップショットテストとは?


● 前回成功時の結果との一致を確認するテスト 


引用:Pythonで スナップショットテスト/ pyconjp2023 - Speaker Deck

そもそも「スナップショットテスト」を初めて知りました。選択肢という点で得られるものがありました。

業務で使える一歩進んだPython使いになるために

speakerdeck.com

すごく大事だと思っているテーマがまとまっています。

● インデントが深すぎると脳への負荷が高すぎる → 複雑度をツールで計測したり、for 文になったら分割。とにかく小さくする。

引用:業務で使える一歩進んだPython使いになるために / To become an advanced user of Python that can be used at work - Speaker Deck

複雑度や凝縮度を計測するツールとしては、以下などが考えられますね🤔

個人的には、複雑度や凝縮度を改善させるためのリファクタリングを実施するにあたって「ツールを活用した目標の設定と評価の導入*1」は必要だと考えています。それぞれがどのような使い勝手なのかを確認し、どのように活用できそうか考えてみたいところです。

スポンサーブース

「この会議を実現するためにスポンサーしていただいている企業の方々とは話さないといけないな」という考えのもとで9割ほどの企業とお話しさせていただきました。ノベルティも沢山いただきました。特に気に入っているのは、Findyさんからいただいた「タイポ用心」のお守りです!

技術カンファレンスではありますが、技術軸でさまざまな企業が取り組む事業を認識したり、解像度を高められたりしたので、良い時間を過ごせたとは思います。

ポスターセッション

ポスターセッションにて、「ノートブックをキレイにするためのTips」というタイトルで発表しました。

speakerdeck.com

ポスター発表では課題に共感いただいたり、打ち手に納得してもらえたり、フィードバックをいただいたりと、良い時間となりました。本発表では、ノートブックにおけるセキュアな情報の扱い方を紹介していましたが、タイムリーなことに、Google Colaboratoryではシークレットを管理する機能がリリースされたようです。とても便利そうですね。

また、これまでオンラインで参加していたコミュニティ(飛騨高山Pythonの会 - connpassはんなりプログラミングの会 - connpass)の方々とも初めてオフラインで挨拶したりとしました。

前回は最後から2番目が発表だったこともあり、それまで物理的にも気持ち的にもバタバタしていたため、発表以外の行動が十分ではなかった気がしています。今回は逆にインタラクティブな発表であったためかバタバタせず、割といろんな行動ができたと思っています。そのため、全体としてとてもいい時間を過ごせたと思っています。

アフターパーティーには参加していなかったのですが、そこでも展示していただいたようです。少しでも話の種になっていたらうれしいです。

その他

スプリントについて、昨年は参加したものの、今回は参加しませんでした。雰囲気が公開されていたのですが、会場や特にランチが良さそうで後悔しています。

発表においてノートパソコンは不要だったことと、荷物の制約もあり今回は持参していませんでした。iPhoneで十分でした。たまにはそんな参加もいいかもしれないです。

改めてですが去年も発表していました。

daikikatsuragawa.hatenablog.com

この一年で、去年の発表やその資料を見てくださって話してくださる方が数人いました。そのときに、あらかじめ自分の考えを理解してもらえていて、一度の発表がジワジワと恩恵をもたらしてくれるんだと実感しています。今回も会期は終えたものの何かにつながればいいなと淡い期待を抱いています。

まとめ

そんな様子でPyCon APAC 2023に参加してきました。運営の方々、本当にありがとうございました。様々な観点で、とても学びの多い機会になりました🙋今年は結果的にスポンサーブースに重心を置いていましたが、「社会の課題に対して、技術を使ってどのように解決するのか(しているのか)」と言った話を伺えたことが、よかったです。…それでは、来年もよろしくおねがいします🙇

次回のPyConJPは2023年9月らしいですね。

「データに関する堅牢性と可読性を向上させるpydanticとpanderaの活用方法の提案」の質疑応答

先日、PyCon JP 2022にて「データに関する堅牢性と可読性を向上させるpydanticとpanderaの活用方法の提案」という題で発表をしました。

2022.pycon.jp

発表資料は以下です。

speakerdeck.com

とてもありがたいことに、想像以上に多くの方に発表を聞いていただくことができました。今回の発表について、確認しただけでも以下のような反響を得ることができました。ありがとうございます。

  • Twitterにおいて約50件のツイート
  • Slidoにおいて約20件の質問

ただし、質問については、発表後の時間が短かったこともあり、回答しきれないものも多く、整理した情報や意見を十分に伝えることができませんでした。そこで、本記事では、いただいた質問に基づき、質問を整理します。そして、それらの質問に対する回答という形式で、発表を補足していきます。※本記事は随時更新予定です。

質疑応答

ライブラリの仕様

Q:pydanticによってイミュータブルなクラスの定義は可能ですか?

pydanticによって、イミュータブル(つまり生成されたインスタンスの状態の変更が不可能)なクラスの定義は可能です。BaseModel(pydantic.BaseModel)内のConfigにより設定を変更することで実現します。以下2つパラメータによる設定例を紹介します。

  • allow_mutation
  • frozen

まずは、allow_mutationの設定をする場合です。allow_mutationについては以下のとおりです。

whether or not models are faux-immutable, i.e. whether setattr is allowed (default: True)

引用元:https://pydantic-docs.helpmanual.io/usage/model_config/

つまり、allow_mutation=Falseにするとイミュータブルなクラスが実現されます。以下のように設定が可能です。

from pydantic import BaseModel
 
class User(BaseModel):
    name: str
    age: int
  
    class Config:
        allow_mutation = False
 
user = User(name="パイソン 太郎", age=20)
user.name = "パイダンティック 次郎"

上記の実装は、イミュータブルなインスタンスに値の再代入を試みていますが、設定の意図通りにエラーが発生します。

(省略)

TypeError: "User" is immutable and does not support item assignment

続いてfrozenの設定をする場合です。frozenについては以下のとおりです。

setting frozen=True does everything that allow_mutation=False does, and also generates a hash() method for the model. This makes instances of the model potentially hashable if all the attributes are hashable. (default: False)

引用元:https://pydantic-docs.helpmanual.io/usage/model_config/

つまり、frozen=Trueにすると、allow_mutation=Falseになり、イミュータブルなクラスが実現されます。

from pydantic import BaseModel
 
class User(BaseModel):
    name: str
    age: int
  
    class Config:
        frozen = True
 
user = User(name="パイソン 太郎", age=20)
user.name = "パイダンティック 次郎"

上記の実装も、イミュータブルなインスタンスに値の再代入を試みていますが、設定の意図通りにエラーが発生します。

このように、pydanticで定義するクラスをイミュータブルにできます。

Q:pandasのデータフレームではstr型はobject型として扱われます。panderaでstr型のカラムの定義は可能ですか?

※当日、曖昧な回答をしてしまい申し訳ございません。以下が整理された回答です。

panderaでstr型のカラムの定義は可能です。str型を含むobject型は、str型として扱われます。それゆえ、panderaによる型のバリデーションによって弾かれることはありません。それに加え、Fieldクラスを組み合わせることで、文字列における「始まりの文字列」、「終わりの文字列」のバリデーションなども可能です。しかし、object型のうち本来str型ではないであろう要素の通過も許されてしまうという問題があります。つまり、他のint型、float型とは異なる挙動となっています。panderaのプロジェクトでは、本件に関連したIssueが公開されており議論がなされています。今後、str型に関するバリデーションについて対応されるかもしれません。

github.com

github.com

以下のような暫定対応により、他のint型、float型と同様の型のバリデーションの実現が可能です。

import pandera as pa
from pandera.typing import Series

class UserSchema(pa.SchemaModel):
    name: Series[str]
    age: Series[int]

    @pa.check("name")
    def check_value_is_string_type(cls, series: Series) -> Series:
        return series.map(lambda v: isinstance(v, str))

Q:pydanticによるバリデーション時のエラーのカスタマイズ(エラーメッセージの変更など)は可能ですか?

可能です。特にエラーメッセージについて説明します。設定方法は大きく2つあります。

まず、Configのerror_msg_templatesに設定を入れることで、エラーメッセージの上書きが可能です。

a dict used to override the default error message templates. Pass in a dictionary with keys matching the error messages you want to override (default: {})

引用元: https://pydantic-docs.helpmanual.io/usage/model_config/

例えば、整数型であるという条件を満たさない場合のエラー(type_error.integer)が発生したときのメッセージとして「整数型ではありません!」を設定しています。

from pydantic import BaseModel
 
class User(BaseModel):
    name: str
    age: int
  
    class Config:
        error_msg_templates = {
            "type_error.integer": "整数型ではありません!",
        }
 
user = User(name="パイソン 太郎", age="二十歳")

整数型ではない値を入れたため、エラーが発生されます。設定した「整数型ではありません!」というメッセージが出力されます。

(省略)

ValidationError: 1 validation error for User
age
  整数型ではありません! (type=type_error.integer)

error_msg_templatesに要素を追加することで、各種エラーにおけるメッセージの設定が可能です。 Fieldに設定した最小値の条件を満たさないエラー(value_error.number.not_ge)に対して「自然数ではありません!」というメッセージを設定します。

from pydantic import BaseModel, Field
 
class User(BaseModel):
    name: str
    age: int = Field(ge=0)
  
    class Config:
        error_msg_templates = {
            "type_error.integer": "整数型ではありません!",
            "value_error.number.not_ge": "自然数ではありません!",
        }
 
user = User(name="パイソン 太郎", age=-1)

自然数ではない値を入れたため、エラーが発生されます。設定した「自然数ではありません!」というメッセージが出力されます。

(省略)

ValidationError: 1 validation error for User
age
  自然数ではありません! (type=value_error.number.not_ge; limit_value=0)

続いて、@validatorpydantic.validator)というデコレーターを付与しているメソッドにおけるエラーに対してメッセージを設定することでもメッセージの指定が可能です。以下は、上記のコードに加え、文字列に空白を含むことを期待するモデルです。

from pydantic import BaseModel, Field, validator
 
class User(BaseModel):
    name: str
    age: int = Field(ge=0)
  
    class Config:
        error_msg_templates = {
            "type_error.integer": "整数型ではありません!",
            "value_error.number.not_ge": "自然数ではありません!",
        }
  
    @validator("name")
    def check_contain_space(cls, v):
        if " " not in v.strip(): # 前後の半角空白を無視
            raise ValueError("半角空白が含まれていません!")
        return v.strip() # 前後の半角空白を削除
 
user = User(name="パイソン太郎", age=20)

半角空白が含まれていない値を入れたため、エラーが発生されます。設定した「半角空白が含まれていません!」というメッセージが出力されます。

ValidationError: 1 validation error for User
name
  半角空白が含まれていません! (type=value_error)

以上の方法でpydanticに関するエラーメッセージの指定(上書き)が可能です。

類似するライブラリとの比較

Q:TypedDictとpydanticの違いは何ですか?

TypedDictとpydanticについて以下のように特徴を比較します。

比較軸 TypedDict pydantic
インストールの要否 標準ライブラリである。PyPIからのインストールは不要。 外部ライブラリである。PyPIからのインストールが必要。
型チェックの精度 構造の表現が可能なのでより詳細な辞書型の方チェックが可能になる。 構造の表現が可能なのでより詳細な辞書型の方チェックが可能になる。
バリデーションの実現方法 あくまで型なので、単体では特にバリデーションは実施されない。 クラスおよびフィールドの定義のみで型についてのバリデーションが実施される。Fieldモジュールにより簡単なバリデーションの実現が可能である。メソッドを定義することにより詳細なバリデーションの実現が可能である。
シリアライズ・デシリアライズの仕様(辞書型) あくまで型なので、特にシリアライズ・デシリアライズなどの振る舞いはない。 辞書型とのシリアライズ・デシリアライズが可能。辞書がネストされている場合も意図どおりインスタンスをの生成が可能である。
シリアライズ・デシリアライズの仕様 (JSON あくまで型なので、特にシリアライズ・デシリアライズなどの振る舞いはない。 JSONとのシリアライズ・デシリアライズが可能。JSONがネストされている場合も意図どおりインスタンスをの生成が可能である。

上記のように、それぞれに異なるメリット・デメリットが存在します。使用状況によって導入を検討してください。

Q:dataclassとpydanticの違いは何ですか?

dataclassとpydanticについて以下のように特徴を比較します。

比較軸 dataclass pydantic
インストールの要否 標準ライブラリである。PyPIからのインストールは不要。 外部ライブラリである。PyPIからのインストールが必要。
型チェックの精度 構造の表現が可能なのでより詳細な型チェックが可能になる。 構造の表現が可能なのでより詳細な型チェックが可能になる。
バリデーションの実現方法 クラスおよびフィールドの定義のみではバリデーションが実施されない。メソッドを定義することにより詳細なバリデーションの実現が可能である。 クラスおよびフィールドの定義のみで型についてのバリデーションが実施される。Fieldモジュールにより簡単なバリデーションの実現が可能である。メソッドを定義することにより詳細なバリデーションの実現が可能である。
シリアライズ・デシリアライズの仕様(辞書型) 辞書型へのシリアライズ・デシリアライズが可能。ただし、ネストされている要素に関してはインスタンスには変換されず、辞書型として格納される。 辞書型とのシリアライズ・デシリアライズが可能。辞書がネストされている場合も意図どおりインスタンスをの生成が可能である。
シリアライズ・デシリアライズの仕様 (JSON dataclasses-jsonという外部ライブラリを使用することでJSONとのシリアライズ・デシリアライズが可能。ネストされている場合も意図どおりインスタンスをの生成が可能である。 JSONとのシリアライズ・デシリアライズが可能。JSONがネストされている場合も意図どおりインスタンスをの生成が可能である。

上記のように、それぞれに異なるメリット・デメリットが存在します。使用状況によって導入を検討してください。

Q:dataclassからpydanticへの移行について有用な情報はありますか?

既存のdataclass(dataclasses.dataclass)を使用したコードに対して、比較的少ない変更でpydanticへ移行する時に有用なモジュールとしてdataclass(pydantic.dataclasses.dataclass)があります。

Dataclasses

If you don't want to use pydantic's BaseModel you can instead get the same data validation on standard dataclasses (introduced in Python 3.7).

引用元:https://pydantic-docs.helpmanual.io/usage/dataclasses/

@dataclassというデコレーターを付与することでバリデーションをしてくれるクラスにしてくれます。つまり、使用している@dataclassdataclasses.dataclass)というデコレーターを付与しているクラスの内容を変更する必要がなく、インポートをするモジュールの差し替えのみでpydanticの使用が可能です。

例えば、従来のdataclass(dataclasses.dataclass)を使用した以下のコードがあったとします。これは期待しない値の格納を許してしまいます。

from dataclasses import dataclass

@dataclass
class User:
     name: str
     age: int

User(name="パイソン 太郎", age="二十歳")

dataclassモジュールをdataclasses.dataclassからpydantic.dataclasses.dataclassに差し替えます。差分は以下です。

- from dataclasses import dataclass
+ from pydantic.dataclasses import dataclass

モジュールを差し替えるのみで、バリデーションが実現され、期待しない値の格納を防いでいます。

from pydantic.dataclasses import dataclass

@dataclass
class User:
     name: str
     age: int

User(name="パイソン 太郎", age="二十歳")
(省略)

ValidationError: 1 validation error for User
age
  value is not a valid integer (type=type_error.integer)

以上より、既存のdataclass(dataclasses.dataclass)を使用しているコードにおいて、モジュールをdataclass(pydantic.dataclasses.dataclass)に差し替えることで、バリデーションを実施してくれるクラスに変えることができます。

ただし、dataclass(pydantic.dataclasses.dataclass)とBaseModel(pydantic.BaseModel)の挙動が異なるようなので注意してください。

Note

Keep in mind that pydantic.dataclasses.dataclass is a drop-in replacement for dataclasses.dataclass with validation, not a replacement for pydantic.BaseModel (with a small difference in how initialization hooks work). There are cases where subclassing pydantic.BaseModel is the better choice.

For more information and discussion see pydantic/pydantic#710.

引用元:https://pydantic-docs.helpmanual.io/usage/dataclasses/

使用場面についての見解

特定の場面に対して「導入すべきか?」という質問が多く挙げられました。断定できないことが恐縮ですが、導入するか否かの意思決定については、各々個人やプロジェクトのさまざまな事情なども組み合わせて検討することをお勧めします。私自身も限られた経験の中で、導入する(したい)場面や、導入しない(したくない、できない)場面が、条件付きで導入できる場面があり、ケースバイケースだと思っています。それゆえ、以降の内容を意思決定の材料とすることをお勧めします。

Q:pydanticとpanderaによるデータのバリデーションにかかる時間を見過ごせない状況では、ウェブアプリケーション全体ではなく、バッチ処理のみに導入するという選択肢はどうですか?

おっしゃるとおり、良い選択肢だと思います。定刻に起動するバッチ処理は比較的、処理時間を気にしなくても良いと思われるので、処理時間に関する懸念は解消されやすいと思われます。場合によっては、期待しないデータを一時的に管理してしまう可能性もありますが、少なくともバッチ処理の頻度では解消できるかと思われます。理想は常にバリデーションしているべきだが、このように、例えば入り口と出口のみだったり、バッチ処理のみなど、部分的にバリデーション を用意するという工夫が考えられます。

Q:機械学習や分析など、ラビットプロトタイピングが有用な場面があります。このような場合にライブラリ(pydanticやpandera)を使用する際、慣れていない場合は開発速度が遅くなります。何か対策はありますか?

私の一意見を回答とさせていただきます。対策としては、状況によって使用するか否かの判断をしています。例に挙げていただいた機械学習や分析、特にGoogle ColaboratoryやJupyter Notebookなど、インタラクティブに実装するものに関して、その判断について考えます。まず判断材料となる要素として「pydanticとpanderaがもたらす」という価値と「慣れていない場合は開発スピードが遅くなる」というリスクを挙げます。この比重は状況によって変わってきます。まず、書き捨てのコードの場合、「使用しない」に比重を置きます。なぜなら、後から再実行しない、つまり堅牢性が重要ではないためです。それに加え、後から見返す必要がない、つまり可読性が重要ではないためです。逆に後から見返し、管理したい、再実行することを考えると、長い目では「使用する」に比重をおいた方が良いと思います。そのとき、ある程度のめどが立つまでは使用はせず、リファクタリングの段階で使用するのが良いのではないかと考えています。また、計算ミスなどが深刻な影響を与える場合、「pydanticとpanderaがもたらす価値」が上がる可能性もあるかもしれません。

Q:定義しているスキーマの対象のAPIのレスポンスや元のデータにおける仕様に変更があった場合、どのような対応をすると良いですか?後方互換性を持たせるなどですか?

通常の開発における修正と同様に、スキーマを定義し直します。ただし、データのスキーマが変化する過渡期については注意が必要です。リリースにおける切り替えの工夫だったり、おっしゃるとおり後方互換性を持たせるなどの対応が必要かと思われます。試したことはないが、Union型やOption型、可能であれば使用を避けたいが、Any型、スキーマ自体の設定の変更などにより許容するデータを調整できるため、過渡期に用意しておく後方互換性に有用な要素になるかとも思われます。

Q:現実のデータセットは必ずしも整理されているとは限らないということは承知していますが、そのような場合でもスキーマを定義、バリデーションを実施することが望ましいですか?

おっしゃるとおり、元のデータセットは必ずしも整理されているとは限りません。そこで取りうる選択肢もいくつか存在すると思われます。例えば、そのようなデータセットを整形などすると思われますが、まず一次受けのタイミングではそのまま受け取り、その後、整形に伴ってpanderaによるスキーマ定義およびバリデーションを実現するという選択肢も考えられます。もしくは、一次受けのタイミングでわかっている範囲での必要最小限のバリデーションのみ実装するという方法も考えられます。これにより、少なくともどのようなデータを扱っているのかを他者が理解することができると思われます。

Q:pydanticを使用せず、panderaのみの使用は可能ですか?

発表では類似の目的と類似の記述方法を持つ2つのライブラリとして併用することを勧めたが、それぞれ独立したライブラリなので問題ない。ただし、panderaの依存関係にpydanticが含まれているため、インストールは必要となる。どうせインストールされるのであれば、併用してみてはどうかというのが私の意見です。

Q:(本発表において)pydanticとpanderaを併用する意図はどのようなものですか?一方のみの使用でも良いのでは?

前提として、状況に応じて、一方のみの使用でも良いと思います。例えば、データフレームを扱わないのにpanderaを使用する必要はありません。逆にデータフレームを扱うような処理においては併用が有効になる可能性があります。改めて、併用を提案したい理由を列挙します。

  • スキーマ定義およびバリデーションが可能な型の範囲が増えること
  • panderaのSchemaModelを使用する場合に併用時の学習コストが少ないこと
  • 依存関係もあり他方を使用している場合リソースに関する懸念が少ないこと(使用しない理由がないこと)

経験に基づく見解

※今回は個人として発表しました。それゆえ、以降は個人の活動や経験に基づき回答します。

Q:発表内容を実際の業務や研究に活用したことがありますか?

私が個人としてPythonによるコーディングを実施する場面は以下2つです。

  • Google Colaboratoryでの分析
  • OSS(主にライブラリ)開発

Google Colaboratoryでの分析では「何度か実行する」かつ「見返す」ようなコードではがあります。そのようなコードの場合、pydanticやpanderaを使用しています。ある意味ドキュメントの代わりもかねて使用しています。逆に、書き捨てのコードでは恩恵が少ないので使用しません。

OSS開発については使用しません。依存関係を増やしてしまうことが一番の理由です。対象のOSSを使用しているプロジェクトの都合なども考えると、依存関係を増やすのはハードルが高いです。ただし、堅牢性、可読性に関する課題感を抱くことはしばしばあり、開発、テスト時にできることとして、型ヒントおよびmypyの導入をしていたりはします。

Q:処理速度が遅くて困った経験はありますか?

自分には「処理速度が遅くて困った経験」がありませんでした。理由は以下で困りようもないのだと考えられます。

  • リアルタイム性が重要な実装ではない(計算時間を待てる)
  • そもそも扱うデータが大規模ではない(かもしれない)

逆にリアルタイム性が重要であったり、大規模なデータを扱う場合は、処理速度が遅く困ることになるかもしれません。

本記事のまとめ

今回の発表および皆様からのコメントを踏まえ、意思決定の事例やユースケースを、導入したか否かにかかわらず知りたいと思いました。可能であれば、類型化できるのではないかと考えています。引き続き、情報収集に努めます。情報提供や質問などあれば、以下までご連絡をください。よろしくお願いいたします。

forms.gle

PyCon JP 2022の振り返り

先日、PyCon JP 2022にスピーカーおよびスプリントリーダーとして参加してきました。

2022.pycon.jp

本記事はその記録です。

カンファレンス

1日目は不参加でした。ただし、Twitterや発表のアーカイブは閲覧し、雰囲気を感じていました。オンラインの恩恵も受けることができました。

2日目から参加しました。オフラインでの技術系のカンファレンスへの参加は初めてで、新鮮でした。企業ブースもたくさん回りました。

カンファレンス感

そして、「データに関する堅牢性と可読性を向上させるpydanticとpanderaの活用方法の提案」という内容で発表しました。

発表直前(サブのモニターがあって発表しやすい)

資料は以下に公開しています。

speakerdeck.com

発表の目的は以下でした。

  • 自分の知見を新たなコミュニティへ伝える(+エコシステムの活性化)
  • 新たなコミュニティへ伝える事により新たなフィードバックを得る

それゆえ、様々な感想や質問をいただいたことは、とてもありがたかったです。こちらについては追々まとめようと思います。

自分の発表以外に、他の方々の発表も聞いていまして、内容から発表時の伝え方や立ち振る舞いまで、様々な観点で学びが多かったです。特に、特定のプロジェクトを軸に話を展開していく方々の話は興味深く、もし次回発表するのであれば、参考にしたいと思いました。

スプリント

3日目は、スプリントに参加しました。遠方からだったこともあり、せっかく参加するのであればと思い、テーマを掲げ、リーダーとして申し込みました。自問自答の末に当初の予定から磨きがかかり、「反実仮想説明法を活用したウェブアプリケーションのMVP開発」というテーマで開発をしました。

これまで執筆した以下の記事に関連したものです。

daikikatsuragawa.hatenablog.com

daikikatsuragawa.hatenablog.com

反実仮想説明法の提供する価値が素晴らしいと思いつつも「具体的にどのように伝えるのが良いか(UI)」という観点で考えたい、可能であれば議論したいと感じていました。そこで、議論の叩きにするためのベースラインとして、まずはウェブアプリケーションとしてカタチにしきろうと思い、MVP開発という体で開発を始めました。

テーマを提案するリーダーでしたが、チームは自分一人でした。そのため、もくもくと作業をしました。「これがもくもく会か…!」とピンときてたりもしました。紆余曲折ありました。本題とは別のところであるライブラリの不具合らしき挙動も発見し、報告したり、個人的に挙動の理解を深めたりできました。ギリギリまでバタバタしましたが、なんとか見せられる状態にしました。当日の成果発表はタイトルだけ書いたスライドを用意し、基本はウェブアプリケーションを実際に動かしながらデモンストレーションをしました。以下はその時の成果発表を後日にまとめたものです。

speakerdeck.com

時間制限があると、これからの時間の取捨選択を強いられ、時間内でのベストを生み出せるのでいいですね。

また、数人の方とお話しさせていただき、それぞれの普段の抱いている課題について共有しました。これがなかなか刺激的で、熱く語り合ってしまいました。

まとめ

そんな様子でPyCon JP 2022に参加してきました。運営の方々、本当にありがとうございました。来年以降も参加したいと思い、すでにネタの思案をしています。様々な観点で、とても学びの多い機会になりました🙋

Pythonによる開発をアップデートするライブラリの紹介

2022年7月29日(金)、30日(土)に開催された「Open Source Conference 2022 Online Kyoto」に参加しました。そこで私(id:daikikatsuragawa)は「Pythonによる開発をアップデートするライブラリの紹介」というテーマで発表しました。

event.ospn.jp

発表資料は以下です。

speakerdeck.com

本記事は、発表に向けて用意した原稿を記事として再構築したものです。目次は以下です。

Pythonによる開発をアップデートするライブラリ

はじめに、Pythonについて説明します。Pythonとは「動的型付けプログラミング言語」のひとつです。その特徴として、さまざまなライブラリがオープンソースソフトウェア(OSS)として公開されていることが挙げられます。例えば、機械学習に関する実装がなされているライブラリが公開されており、それを利用することで機械学習の実現が可能です。PythonサードパーティーソフトウェアリポジトリであるPyPIには、38万を超えるソフトウェアやライブラリが登録されています。

pypi.org

そして、GitHubの調査によると、Pythonは3年連続で人気プログラミング言語の第2位にランクインしており、多くの開発者に親しまれています。

octoverse.github.com

本記事はそんなPythonの開発について紹介します。具体的には「Pythonによる開発をアップデートするライブラリ」を紹介します。

まず、本記事の背景と動機を共有します。まず、「開発における理想と現実」について説明します。みなさん、開発における理想を想像してみてください。私なら「成果物が正常に動作すること」「保守性が高いこと(複数人での開発が可能)」です。 そのような理想に対して、現実が一致しない場合があります。具体的には「成果物に不具合が生じることがあること」や「開発の保守性が高いという自信が無いこと」などが挙げられます。「理想に対して、現実が一致しない場合がある」ということは、「理想と現実にギャップが存在する」と言い換えることが可能です。このギャップを改善することで現実は理想に近づくと考えられます。そのため、ここで言うギャップを整理します。理想が「成果物が正常に動作すること」であるのに対して、現実は「成果物に不具合が生じることがあること」だったとします。この時のギャップは「開発者が不具合を埋め込んでしまうこと」です。理想が「開発の保守性が高い(複数人での開発が可能)」であるのに対して、現実は「開発の保守性が高いという自信が無いこと」だったとします。この時のギャップは「開発者が保守性の低いコーディングをする」です。このように「開発における理想と現実」にはギャップが存在しているということがわかります。

理想 現実 理想と現実のギャップ
成果物が正常に動作すること 成果物に不具合が生じることがあること 開発者が不具合を埋め込んでしまうこと
保守性が高いこと(複数人での開発が可能) 開発の保守性が高いという自信が無いこと 開発者が保守性の低いコーディングをする

ここまでで理想と現実の間にはギャップがあることがわかりました。続いて、そこでギャップを解消する手段について考えます。例えば「個人の能力の向上」が挙げられます。ただし、これは個人に依存する為、不確実性が大きいです。他に「仕組みの導入」があります。つまり、開発プロセスの改善です。これは仕組みを規約とすることで実現可能性が高くなります。以上より、開発プロセスの改善により理想と現実のギャップの解消を試みます。

開発プロセスの改善」を試みるために、理想と現実のギャップを開発プロセスの課題と捉え直します。まず「開発者が不具合を埋め込んでしまうという」という課題は「不具合を埋め込ませない開発プロセスの構築が必要」というような開発プロセスの課題として捉え直すことが可能です。また「開発者が保守性の低いコーディングをする」といった課題は「一定の保守性を担保する開発プロセスの構築が必要」というような開発プロセスの課題と捉え直すことが可能です。つまり、理想と現実のギャップというのは開発プロセスの課題と言えます。

理想と現実のギャップ 開発プロセスの改善
開発者が不具合を埋め込んでしまうこと 不具合を埋め込ませない開発プロセスの構築が必要
開発者が保守性の低いコーディングをする 一定の保守性を担保する開発プロセスの構築が必要

改めてお伝えすると、課題は開発プロセスの課題と変換が可能です。開発プロセスの課題はツールによって改善が期待されます。また、Pythonには様々なライブラリが存在します。これらを加味して、本記事では「有用なライブラリを導入し利用」することで開発プロセスの改善を考えます。以上の背景・動機により「Pythonによる開発プロセスを改善(つまり、開発をアップデート)する有用なライブラリを紹介します。

本記事で紹介するライブラリはこのようになっています。まず、pydanticです。モデルの定義に基づくバリデーションを実現します。次に、panderaです。スキーマの定義に基づくデータフレームのバリデーションを実現します。そして、hypothesisです。入出力に関するプロパティの定義に基づくProperty-based testingを実現します。最後に、streamlitです。必要最小限のウェブアプリケーションを簡単に実現します。pydantic、pandera、hypothesisはそれぞれ導入による堅牢性と可読性の向上が期待されます。streamlitは、早期に提供価値の評価を実現させます。

本記事で紹介するライブラリについて「伝えること」と「伝えないこと」は以下です。

  • 伝えること
    • ライブラリの概要
    • ライブラリの利点
    • 簡単な利用例
  • 伝えないこと
    • 詳細な利用例

それゆえ、本記事を知るキッカケとして捉えていただけると幸いです。そして、気になったら是非調べてみてください。

型ヒントとは?

以後、上記で紹介したライブラリについて紹介します。その前提として、事前に理解しておくことが望ましいPythonの「型ヒント」についての説明をします。型ヒントとは、「変数の定義」、「関数の引数や戻り値の定義」に型のヒントを付与する記法です。Pythonの3.5以降導入されています。以下、型ヒントを使ったコードです。

name: str = "パイソン 太郎"

def calculate_division(numerator: int, denominator: int) -> float:
   return numerator / denominator

例えばこのコードの場合、nameというような変数に文字列を代入しています。これがstring型だということは暗黙的に理解できるのですが、このように明示的に示すこともできます。これが型ヒントです。他にも関数の引数、戻り値の定義にもこのように型ヒントを付与が可能です。これによりこの変数や関数の引数、戻り値がどんな型を期待しているのかという情報を読み取ることが可能です。以上よりコードの可読性の向上が見込まれます

型ヒントの振る舞いについて説明します。実は、実行時に型のチェックはしません。そのため型ヒントに対して、期待していない状態だったとしてもエラーにならないです。あくまで開発者向けのコメントのような扱いです。サードパーティのツール、例えばmypyと組み合わせることで静的チェックを実現したりします。

www.mypy-lang.org

以上より型ヒントを使うこととサードパーティのツールと組み合わせることで堅牢性の向上が見込まれます。

型ヒントの記述方法について説明します。基本は大きく三つ記述方法があります。一つ目は変数に関して、直後にコロン(:)と型を記述します。

name: str = "パイソン 太郎"

続いて、関数の引数については、変数と同じで各引数の直後にコロンと型を記述します。関数の戻り値に関しては関数の定義中のコロンの直前にハイフンと大なりからなる矢印のような記号(->)と型を記述します。

def calculate_division(numerator: int, denominator: int) -> float:
   return numerator / denominator

続いて、複雑な型の指定についてです。先ほどは int型、float型、str型の例を挙げました。それに加えて、dict型やlist型などの構造を持つ型の指定も可能です。念のためお伝えすると、以降で説明に挙げるコードはPython 3.8までの記法です。まず、dict型、list型などの要素の型の指定が可能です。まず、Dictというクラスをインポートし、これを型ヒントとして使います。この時、dict型のキーおよびバリューの型の指定が可能です。

from typing import Dict

user_and_age: Dict[str, int] = {'パイソン 太郎': 20}

複数の型の指定も可能です。以下のコードでは、Unionというクラスをインポートし、型ヒントとして指定したい型を複数種、指定します。

from typing import Union

str_or_int: Union[str, int] = 0 # or パイソン 太郎"

他にも値を持っていることを必須としない変数には、必須ではない(Optional)という指定が可能です。

from typing import Optional

optional_int: Optional[int] = None # or 0

どんな値でも受け入れるという場合は、任意(Any)という指定が可能です。

from typing import Any

any: Any = 0 # or "パイソン 太郎", None, {"パイソン 太郎": 20} ...

関数の返り値が存在しない(None)という指定も可能です。

from typing import Any

def return_none(input: Any) -> None:
    return None # もしくはリターンをしない

最後に、プリミティブな型以外の指定も可能です。先ほどのDictというクラスを使った例なども該当しますが、プリミティブな型以外の指定も可能です。つまり、自作のクラスも型ヒントとしての指定が可能です。例えば、SampleClassというクラスを定義したとします。これに対して、インスタンスを生成する際、そのインスタンスの型はSampleClassです。この時、SampleClassを型ヒントとしての指定が可能です。関数の引数、返り値の場合も同様です。

class SampleClass:
   pass

sample_class: SampleClass = SampleClass()

def return_input(input: SampleClass) -> SampleClass:
   return input

型ヒントについてのまとめをお伝えします。型ヒントとは、変数の定義、関数の引数や戻り値の定義に型のヒントを付与する記法です。型ヒントの振る舞いとしては実行時に型のチェックはしません。それゆえ、たとえ誤っていてもエラーが生じません。そこで、サードパーティのツール、例えばmypyと組み合わせることで静的チェックの実現が可能です。これにより可読性と堅牢性の向上が期待されます。

以降、型ヒントを活かして可読性と堅牢性を向上させるpydanticとpanderaを紹介します。

モデルの定義に基づくバリデーションを実現するpydantic

それでは、モデルの定義に基づくバリデーションを実現するpydanticについて紹介します。

みなさん、複数の部品で構成されるシステムを開発していますか?多くのシステムは、複数の部品で構成されていると考えられます。ここでの部品とは、モジュール、クラス、メソッドなどのことです。基本的には、各部品が役割と責任を持ち、連携して動作します。つまり、各部品の入出力を把握しておけば、システムの全てを把握する必要はありません。不要です。入出力にはdict、JSONといった構造を持つものも多く使われます。

ここでは、複数の部品から構成されるシステムの開発において、そのような課題を2つ取り上げます。まずは「入出力で扱うデータの定義がわからない」という可読性の課題です。他の部品の出力を入力として受け取る場面があるかと思います。この時に他の部品の出力の構造が分からなければ、他の部品の実装を深く調べる必要があるといった可読性の課題が挙げられます。例えば部品Yが部品Zにデータを格納したJSONを渡すとします。この時、部品Zからすると、JSONなのはともかく、その構造、要素は何かが理解できない可能性があります。

また、「入出力で扱うデータが正しくない」という堅牢性の課題が挙げられます。他の部品の出力を把握しているものの期待と異なる、正しくないデータを受け取る場面を指します。例えば、受け取った年齢の値が「−1」、型が異なる、期待しているデータがないといった場合です。例えば部品Yが部品Zにデータを格納したJSONを渡すとします。この時、部品Zはどんな内容のJSONを受け取るのかを把握しているものの、受け取ったデータが正しくない可能性があります。

先に挙げた課題の解決に期待されるライブラリとしてpydanticを紹介します。pydanticとはモデルを定義することでデータのバリデーションを実現するライブラリです。それに加え、dict型やJSONとのシリアライズ/デシリアライズも可能で、部品の入出力に有用です。

pydantic-docs.helpmanual.io

PyPIで公開されており、このコマンドによりインストールが可能です。

!pip install pydantic

ライセンスはMIT Licenseです。

github.com

pydanticを導入することにより先ほどの課題の解決が期待されます。入出力で扱うデータの定義がわからないという課題については、モデルの定義をコードとして記述することにより把握が可能となります。入出力で扱うデータが正しくないという課題については、定義に基づくバリデーションにより正しいデータのみが存在する状態となります。以降、具体的なpydanticの利用方法についてお伝えします。

pydanticの利用例としてまずはモデルの定義について紹介します。以下はpydanticによりモデルを定義しているコードになります。

from pydantic import BaseModel, Field

class User(BaseModel):
   name: str
   age: int = Field(ge=20)

pydanticのモジュールであるBaseModelを継承した任意のクラスがモデルの定義となります。今回はUserというクラスを定義しました。インスタンス変数は名前(name)と年齢(age)の2つです。また、このモデルの定義のさい、型の情報に加え、有効範囲の定義などが可能です。例えば、この年齢は20歳以上の場合に受け付けます。続いて、以下はインスタンスを生成するコードです。

external_data = {
   'name': 'パイソン 太郎',
   'age': 20
}
user = User.parse_obj(external_data)

dict型の変数からインスタンスを生成するparse_objというメソッドがあります。これにより、従来、dict型やJSONを扱っていた場合、このように利用することで、扱っているデータの定義をコードから読み取ることが可能です。つまり、可読性が保たれます。続いて、別のインスタンスを生成します。試しに年齢が19歳という有効範囲外の値を持つインスタンスの生成を試みます。

external_data = {
   'name': 'パイソン 太郎',
   'age': 19
}
user = User.parse_obj(external_data)

この時、ValidationErrorというエラーが生じます。つまり、定義を満たさないインスタンスは生成されません。つまり、堅牢性が保たれます。一部を省略しますが、ValidationErrorの出力は以下のようになっています。

(省略)
ValidationError: 1 validation error for User
age
  ensure this value is greater than or equal to 20 (type=value_error.number.not_ge; limit_value=20)

年齢について「20以上という定義を満たしていない(ensure this value is greater than or equal to 20)」という旨が書かれています。このようにエラーの詳細の確認が可能です。続いて、pydanticによって定義したモデルを引数とする関数について説明します。

from pydantic import validate_arguments

@validate_arguments
def input_user(user : User) -> None:
   pass

実現するために記述する内容は大きく2つです。まずは関数に対して、引数のバリデーションを実行するデコレータであるvalidate_argumentsを付与します。もう一つはpydanticで定義したクラスを引数の型ヒントとして指定します。そして、以下が実行です。

external_data = {
   'name': 'パイソン 太郎',
   'age': 20
}
input_user(external_data)

pydanticのBaseModelを継承したクラスはdict型、JSONとのシリアライズおよびデシリアライズをしてくれるため、dict型のままでの関数への入力が可能です。以下のコードでは定義を満たすため、成功します。有効範囲外の値を持つ場合、ValidationErrorが生じます。

external_data = {
   'name': 'パイソン 太郎',
   'age': 19
}
input_user(external_data)

入力として与えるタイミング、つまり、関数内で記述した処理を実行する前にエラーが発生します。それゆえ、不要な計算は実施されません。続いて、Userというクラスを返り値とする関数について紹介します

def output_user() -> User:
    external_data = {
        'name': 'パイソン 太郎',
        'age': 20
    }
    return User.parse_obj(external_data)

この関数は内部で任意の処理をしたとして、Userインスタンスを生成し、これを返り値とします。また、部品間のやりとりが実行環境が違うという場合は、インスタンスのやり取りができないため、dict型やJSONに変換します。

output_user().dict()

このような場合でも以下のように有効範囲外の値があれば、関数実行中にエラーが生じます。

def output_user() -> User:
    external_data = {
        'name': 'パイソン 太郎',
        'age': 19
    }
    return User.parse_obj(external_data)

つまり、この関数の返り値は正常なものであるということが担保されます。ここまでは簡単な型であったり、数値の有効範囲を満たすか否かを定義し、バリデーションを実現していました。それに加え、詳細なバリデーションの実現も可能です。例えば、名前の要件として、半角空白(” ”)を含むとします。

from pydantic import BaseModel, Field, validator
import unicodedata

class User(BaseModel):
   id: int
   name: str # 半角空白を含む(※前後以外)
   age: int = Field(ge=20)
  
   @validator("name")
   def check_contain_space(cls, v):
       if " " not in v.strip(): # 前後の半角空白を無視
           raise ValueError("ensure this value contains spaces")
       return v.strip() # 前後の半角空白を削除

この要件に対するバリデーションをデコレーターとメソッドにより実現させます。まず、メソッドを用意します。今回はcheck_contain_spaceという、前後を除いて半角空白が含まれるかを判定し、含まれない場合にエラーを発生させるメソッドを用意しました。これに対し、validatorというデコレーターを付与します。ここに対象とするインスタンス変数を指定します。今回はnameを指定します。これにより、デコレーターとメソッドによるバリデーションが可能です。この記述におけるメソッドを工夫すると、詳細なバリデーションの実現が可能です。

ここまでお伝えしたpydanticについてのまとめです。まず複数の部品によって構成されるシステムの開発について各部品が役割と責任を持ち連携しているということをお伝えしました。ただ課題もあります。まだ入出力で扱うデータの定義が分からないという可読性の課題が考えられます。そして、入出力で扱うデータが正しくないという堅牢性の課題が考えられます。そのような課題を解決する手段としてpydanticを紹介しました。これはモデルの定義をすることでデータのバリデーションを実現するライブラリです。モデルの定義により、コードから要件の把握が可能です。また、定義に基づくバリデーションにより正しいデータのみが存在する状態にできます。

スキーマの定義に基づくデータフレームのバリデーションを実現するpandera

続いて、データフレームの定義に基づくバリデーションを実現するpanderaについて紹介します。

みなさん、データフレームを使っていますか?実は様々な種類が存在していますが、今回挙げるデータフレームというのはpandasというライブラリのDataFrameとします。データフレームは、表形式のデータの取り込み、加工、集計、分析に利用されるものです。データ分析や機械学習などで活躍しています。

sepal_length sepal_width petal_length petal_width target
0 5.1 3.5 1.4 0.2 0
1 4.9 3 1.4 0.2 0
2 4.7 3.2 1.3 0.2 0
3 4.6 3.1 1.5 0.2 0
4 5 3.6 1.4 0.2 0

そのようなデータフレームにおける課題を挙げます。まずは「意図していない値を格納してしまう」といった課題です。以下のデータフレームはその例です。

sepal_length sepal_width petal_length petal_width target
146 6.3 2.5 5 1.9 2
147 6.5 3 5.2 2 2
148 6.2 3.4 5.4 2.3 2
149 5.9 3 5.1 1.8 2
150 ◯△□ 3 4.35 1.3 3

例えば、数値を期待しているsepal_lengthという列に「◯△□」という文字列が格納されてしまったりします。また、targetという列は、「0」/「1」/「2」というカテゴリカルな数値を期待しています。しかし、期待されている値ではない「3」が格納されてしまっています。このように意図しない値を格納してしまうという課題が発生します。

次に「他者・未来の自分がコードから内容を読み取れない」といった課題です。例えば、以下はデータフレーム(scikit-learnより取得)を扱うコードです。

scikit-learn.org

import pandas as pd
from sklearn.datasets import load_iris

data = load_iris()
iris = pd.DataFrame(data.data, columns=data.feature_names)
iris["target"] = data.target
iris.head()

このirisという変数はデータフレーム型のインスタンスです。変数名からアヤメについての情報が格納されていることの想像が可能です。しかし、このカラム、およびその値が数値なのか文字列なのかといった要件について、コードから読み取ることは不可能です。これでは、他者がコードから詳細を読み取れず、協調作業は困難になります。それに加え、未来の自分もこの内容を思い出すのは困難でしょう。このように「他者・未来の自分がコードから内容を読み取れない」という課題が発生します。

そこでpanderaというようなライブラリを紹介します。panderaとはスキーマ(つまり、構造)の定義により、データフレームのバリデーションを実現するライブラリです。

pandera.readthedocs.io

PyPIで公開されており、このコマンドによりインストールが可能です。

!pip install pandera

ライセンスはMIT Licenseです。

github.com

panderaは先ほど挙げた課題の解決に有用です。まず「意図しない値を格納してしまう」という課題がありました。panderaを導入することによってデータフレームのバリデーションを実現し、意図しない値の格納を防ぐことが可能です。続いて、「他者・未来の自分がコードから内容を読み取れない」といった課題がありました。panderaを導入に伴いスキーマを明示的に定義することで、コードから内容の読み取りが可能です。続いて、具体的なpanderaの利用例について紹介をします。panderaによってバリデーションを実現する方法として以下2種類のクラスの選択が可能です。

DataFrameSchema SchemaModel

今回はSchemaModelというクラスを使う方法を紹介します。こちらは、スキーマの定義がpydanticとインタフェースが類似しているため、pydanticを利用している方におすすめです。

それではpanderaの利用例について説明します。まず準備としてアヤメのデータセットを準備します。説明を簡単にするために、各カラム名は単純なものに変換しています。

import pandas as pd
from sklearn.datasets import load_iris

data = load_iris()
iris = pd.DataFrame(data.data, columns=data.feature_names)
iris["target"] = data.target
iris = iris.rename(
   columns={
       "sepal length (cm)": "sepal_length",
       "sepal width (cm)": "sepal_width",
       "petal length (cm)": "petal_length",
       "petal width (cm)": "petal_width",
   }
)

先ほどのコードの実行によって、以下のようなデータフレームが生成されます。上から5件のレコードを表示させています。

iris.head()
sepal_length sepal_width petal_length petal_width target
0 5.1 3.5 1.4 0.2 0
1 4.9 3 1.4 0.2 0
2 4.7 3.2 1.3 0.2 0
3 4.6 3.1 1.5 0.2 0
4 5 3.6 1.4 0.2 0

カラムは5つです。がく片、花弁の長さ、幅はfloat型の数値です。アヤメの種類が「0」/「1」/「2」のカテゴリカルな数値として格納されています。また、データの統計情報を確認します。

iris.describe()
sepal_length sepal_width petal_length petal_width target
count 150 150 150 150 150
mean 5.843333 3.057333 3.758 1.199333 1
std 828066 0.435866 1.765298 0.762238 0.819232
min 4.3 2 1 0.1 0
25% 5.1 2.8 1.6 0.3 0
50% 5.8 3 4.35 1.3 1
75% 6.4 3.3 5.1 1.8 2
max 7.9 4.4 6.9 2.5 2

これによりそれぞれのカラムの最大値が分かります。この情報はスキーマの定義の際に使います。それではpanderaを使ってスキーマを定義します。panderaのスキーマはこのように定義します。

import pandera as pa
from pandera.typing import Series

class IrisSchema(pa.SchemaModel):
   sepal_length: Series[float] = pa.Field(gt=0, le=8)
   sepal_width: Series[float] = pa.Field(gt=0, le=5)
   petal_length: Series[float] = pa.Field(gt=0, le=7)
   petal_width: Series[float] = pa.Field(gt=0, le=3)
   target: Series[int] = pa.Field(isin=[0, 1, 2])

   class Config:
       name = "BaseSchema"
       strict = True
       coerce = True

panderaのSchemaModelを継承したIrisSchemaというクラスを定義します。そして、列ごとの要件を設定していきます。がく片、花弁の長さ、幅はfloat型の数値と設定します。それに加え、それぞれの先ほどの統計情報を参考に最小値・最大値を設定します。種類を示す列に「0」/「1」/「2」のいずれかが入ると設定します。それでは。この定義したスキーマを使ってバリデーションを実施してみます。先ほど定義したクラスのメソッドであるvalidateに対して、データフレームを入力として与えることでバリデーションが実施されます。まずは、定義の内容を満たすデータフレームを入力してみます。すると、同じデータフレームが出力されます。何事もないですが、これは問題がなかったことを意味します。これによりデータフレームのバリデーションが実現されます。

iris = IrisSchema.validate(iris)
iris.head()
sepal_length sepal_width petal_length petal_width target
0 5.1 3.5 1.4 0.2 0
1 4.9 3 1.4 0.2 0
2 4.7 3.2 1.3 0.2 0
3 4.6 3.1 1.5 0.2 0
4 5 3.6 1.4 0.2 0

次に、意図しないレコードを追加したデータフレームを用意します。ここでの意図しないレコードとして、targetに「3」を入れます。

invalid_record = {
   "sepal_length": 5.8,
   "sepal_width": 3.0,
   "petal_length": 4.35,
   "petal_width": 1.3,
   "target": 3, # invalid value
}
invalid_iris = iris.append(invalid_record, ignore_index=True)
invalid_iris["target"] = invalid_iris["target"].astype(int)

この列の定義として、「0」/「1」/「2」のいずれかにあてはまるようにしているため、意図しないレコードとなってしまいます。以下が、先ほどのレコードを追加した、バリデーション前のデータフレームです。

invalid_iris.tail()
sepal_length sepal_width petal_length petal_width target
146 6.3 2.5 5 1.9 2
147 6.5 3 5.2 2 2
148 6.2 3.4 5.4 2.3 2
149 5.9 3 5.1 1.8 2
150 5.8 3 4.35 1.3 3

インデックスが150のレコードのtargetに「3」といった意図しない値が入っています。この意図しないレコードを含むデータフレームに対して、バリデーションを実施してみます。

invalid_iris = IrisSchema.validate(invalid_iris)

すると、以下のようなSchemaErrorというエラーが発生しました。

(省略)

SchemaError: <Schema Column(name=target, type=DataType(int64))> failed element-wise validator 0:
<Check isin: isin({0, 1, 2})>
failure cases:
   index  failure_case
0    150             3

エラーの内容を読んでみると、「インデックスが150のレコードでエラーが発生している」ということが書いてあります。このように、panderaによるデータフレームのバリデーションが実現されます。

panderaのまとめです。まずは、データフレーム(pandas.DataFrame)について紹介しました。データフレームは表型式のデータの取り込み、加工、集計、分析に利用されます。 データ分析/機械学習などで活躍します。ただし、「意図しない値を格納してしまう」「他者・未来の自分がコードから内容を読み取れない」という課題を挙げました。そのような課題の解決が期待されるライブラリであるpanderaを紹介しました。これは、データフレームのスキーマ(構造)を定義することでデータフレームのバリデーションを実現するライブラリです。これにより、「バリデーションにより意図しない値の格納を防ぐ」「スキーマを明示的に記述することでコードから内容の読み取りが可能に」ということが実現されます。

入出力に関するプロパティの定義に基づくProperty-based testingを実現するhypothesis

続いて、入出力に関するプロパティの定義に基づくProperty-based testingを実現するhypothesisについて紹介します。

みなさん、単体テストは実施していますか?単体テストはプログラムを構成する小さな部品(関数/メソッド)が意図した振る舞いか否かを検証するテストです。Pythonではunittestやpytestというテスト用のフレームワークが有名です。一般的によくみられる単体テストの種類として「Example-based testing」があります。関数やメソッドに対して、任意の基準で入力値を選択し、出力値や事後状態を確認することにより振る舞いを検証する手段です。任意の基準とは、ランダムに選択したり、境界値テストに従って選択するなどを意味します。)例えば、除算するメソッドに対して、「3」と「12」という入力を与えて「4」が出力されることを確認するテストを指します。

そのようなExample-based testingにおける課題として「テストの品質がテスト作成者に依存してしまう」といったものが挙げられます。それにより、テスト作成者の想定内の内容で不十分になってしまう危険があります。例えば、境界値テストなどの手法を知らず要件を満たさない検証となったといったことが生じます。他にも、除算するメソッドに対して、適当な入出力での検証は実施しているが、分母が「0」の場合、入力が「None(null)」の場合といったエッジケースを見逃すといったことが生じます。また、冗長なテストを書いてしまう危険があります。例えば、複数の例を設定し検証したが特に意味がないといったことです。

そのような単体テストの課題に対して、Property-based testingが有用です。Property-based testingとは、入出力に関するプロパティを定義し多数の入力を与え検証する方法です。入出力に関するプロパティの例として、除算するメソッドに対して、「入力値はint型の自然数、ただし分母に0、入力にNone(null)は許可しない」、「出力はfloat型の数値」といったことが挙げられます。

そのようなProperty-based testingを実現するライブラリとしてhypothesisがあります。入出力に関するプロパティの定義に基づくProperty-based testingを実現するライブラリになっています。PyPIで公開されており、このコマンドによりインストールが可能です。

hypothesis.readthedocs.io

PyPIで公開されており、このコマンドによりインストールが可能です。

!pip install hypothesis

ライセンスはMozilla Public License Version 2.0です。

github.com

Property-based testingを実現するhypothesisは先ほど挙げた単体テストにおける課題に有用です。課題としてテストの品質がテスト作成者に依存してしまうといった課題がありました。これに対して、hypothesisおよびProperty-based testingの導入によりテスト作成者に依存しないテストの品質の担保が実現されます。

それではhypothesisの利用例についてお伝えします。まずはテスト対象の関数を用意します。

# main.py

def calculate_subtraction(a: int, b: int):
  return a - b

calculate_subtractionという関数を用意しました。概要としては、入力された2つの整数を減算します。入力は整数(int型)を2件、出力は整数(int型)になります。

calculate_subtractionに対して、単体テストの作成を試みます。プロパティは、入力がそれぞれint型の自然数xとyです。そして、xがyより大きいとします。この時、出力は0以上1以下となります。ひとまず、このプロパティの実装を試みた結果が以下です。

# test_main.py

from main import calculate_subtraction
from hypothesis import given, strategies

@given(x=strategies.integers(), y=strategies.integers())
def test_calculate_subtraction(x, y):
  assert 0 < calculate_subtraction(x, y)

これにより、入力x、yにはランダムな数字が設定され、テストは複数回実施されます。実はこの単体テストの実装には不備がありまして、その辺りの解消を試みつつhypothesisの挙動を紹介します。pytestコマンドにより実行します

pytest test_main.py

すると、AssertionErrorが生じました。

Falsifying example: test_calculate_subtraction(
   x=0, y=0,
)

(省略)

FAILED test_main.py::test_calculate_subtraction - assert 0 < 0

内容を確認すると、関数の出力がプロパティで設定した要件(0より大きい)を満たさなかった事によるエラーだということがわかります。その時の入力をみてみると、入力として想定していた自然数ではない値(0)が与えられていました。あらかじめ実装したかったプロパティが実現できていないようなので修正します。改めて実装からプロパティを考え直すと、入力を自然数としたいところ、0以下を含む整数となっていたようです。修正した結果が以下のコードです。入力x、yの最小値に1を設定し入力を自然数に限定しています。

  # test_main.py

  from main import calculate_subtraction
  from hypothesis import given, strategies

- @given(x=strategies.integers(), y=strategies.integers())
+ @given(x=strategies.integers(min_value=1), y=strategies.integers(min_value=1))
  def test_calculate_subtraction(x, y):
      assert 0 < calculate_subtraction(x, y)

pytestコマンドにより実行します。すると、AssertionErrorが生じました。

Falsifying example: test_calculate_subtraction(
   x=1, y=1,
)

(省略)

FAILED test_main.py::test_calculate_subtraction - assert 0 < 0

内容を確認すると、関数の出力がプロパティで設定した要件(0より大きい)を満たさなかった事によるエラーだということがわかります。確認すると、入力として想定していたx>yを満たさないことがわかります。改めて、以下は、xがyより大きいという条件を設定していない単体テストです。修正した結果が以下のコードです。

  # test_main.py
  
  from main import calculate_subtraction
  from hypothesis import assume, given, strategies
  
  @given(x=strategies.integers(min_value=1), y=strategies.integers(min_value=1))
  def test_calculate_subtraction(x, y):
+     assume(x > y)
       assert 0 < calculate_subtraction(x, y)

関数の入力に与える前にxとyを比較し、条件を満たすものだけ検証するようにしています。この修正した単体テストを実行してみると、問題なく通ります。このようにhypothesisにより、Property-based testingが実現されます。この時の施行回数は100回でした。具体的には、以下に挙げるような値をランダムに生成し、検証しているようです。

x y
1 30604 30261
2 109 5
3 10694612245883426162890217387823834314 9

hypothesisのまとめです。まず、Example-based testing(一般的によくみられる単体テスト)について説明しました。関数やメソッドに対して、任意の基準(例:ランダム/境界値テスト)で入力値を選択し、出力値や事後状態の確認により振る舞いを検証すると、いう手法です。「テストの品質が実装者に依存」という課題を挙げました。それに対して、Property-based testingを紹介しました。これは、入出力に関するプロパティを定義し多数の入力を与え検証する手法です。そして、hypothesisを紹介しました。これは、入出力に関するプロパティの定義に基づくProperty-based testingを実現するライブラリです。これにより、「Property-based testingによるテスト作成者に依存しないテストの品質を担保」が実現されます。

必要最小限のウェブアプリケーションを簡単に実現するstreamlit

本記事で紹介するライブラリは次が最後です。必要最小限のウェブアプリケーションを簡単に実現するstreamlitについて紹介します。

前提として、Minimum Viable Product(MVP)について説明します。MVPとは、ユーザーに必要な最小限の価値を提供できるプロダクトです。提供しようとしてる価値の評価に有用だと言われています。例えば、ユーザーに移動という価値を与えるために、自動車を開発しているとします。この時、「そもそもユーザーが移動を必要としているのか」を検証したい、とします。しかし、自動車の開発というのはとても大規模で大変なものになります。完成してから価値の評価をすることを考えます。また、「実は移動には想定していた価値がなかった」と評価されたとします。すると、それまでの労力や費用などの損失が大きくなってしまいます。そこで、移動という価値を評価するために、まずはスケートボード、自転車を開発します。これにより、そもそもの移動の価値やそれに伴い、自動車の開発の方向性を定めたりとできます。MVPとはこの時のスケートボードや自転車を指します。これらよりソフトウェア開発、特にウェブアプリケーションの開発においても、必要最小限、動作する状態にすることが望ましいと考えられます。

そこで streamlitというライブラリが有用です。streamlitは ウェブアプリケーション、特にUIの開発を簡単に実現するライブラリです。特に機械学習を扱うような大規模で複雑な開発におけるMVPの開発に有用だと考えられます。

streamlit.io

PyPIで公開されており、このコマンドによりインストールが可能です。

pip install streamlit

ライセンスはApache License 2.0です。

github.com

デモンストレーションとして、streamlitで実現する予測をするウェブアプリケーションを作成したので紹介します。概要としては、学習済みの機械学習モデルによりアヤメの品種を予測するものです。。背景(シナリオ)は、もともとは分析・検証をNotebookで実施していたがそもそも価値があるのかを評価するためにMVPを開発するものとします。ウェブアプリケーションの仕様については、がく片の長さ、がく片の幅、花弁の長さ、花弁の幅を入力とし、最も可能性が高いアヤメの品種を予測し出力するものです。デモンストレーションのために用意したものはひとつのPythonファイルのみです。以下のコマンドにより起動します。

streamlit run app.py

このように一つのPythonファイルのみでもウェブアプリケーションの実現が可能です。以下、streamlitリストによって生成したアヤメ品種予測フォームです。

アヤメ品種予測フォーム(予測前)

フォームには4つの入力欄が表示されています。これらに数値を入力します。数値を入力する際、あらかじめ設定された上限下限の制約に従う必要があります。制約から外れた値の入力はできません。そして、全ての項目を入力後に「予測」と書かれたボタンを押すと、以下のように予測結果が表示されます。

アヤメ品種予測フォーム(予測後)

予測結果の上部には入力値を表示させています。そして、下部には出力として予測されるアヤメの品種を表示させています。また、再度フォームへ入力し、予測を実行することも可能です。

先ほど紹介したようなウェブアプリケーションの実装内容について紹介します。まずは streamlitとは直接関係はないですが、機械学習モデルを作成します。

import pandas as pd
from sklearn.datasets import load_iris
from sklearn.linear_model import LogisticRegression
import streamlit as st

iris = load_iris()
x = pd.DataFrame(iris.data, columns=iris.feature_names)
y = pd.DataFrame(iris.target, columns=["target"])

model = LogisticRegression(random_state=123)
model.fit(x, y)

参考までに、ロジスティック回帰という分類手法を使ってアヤメの種類の予測を実現する機械学習モデルを作成しました。続いて、streamlitの入力フォームとボタンの作成を行います

st.title("アヤメ品種予測フォーム")

with st.form("アヤメ品種予測フォーム"):
   st.write("アヤメの詳細を入力してください。")
   sepal_length = st.number_input(
       "sepal length (cm)", min_value=0.0, max_value=8.0, value=(0.0+8.0)/2, step=1.0)
   sepal_width = st.number_input(
       "sepal width (cm)", min_value=0.0, max_value=5.0, value=(0.0+5.0)/2, step=1.0)
   petal_length = st.number_input(
       "petal length (cm)", min_value=0.0, max_value=7.0, value=(0.0+7.0)/2, step=1.0)
   petal_width = st.number_input(
       "petal width (cm)", min_value=0.0, max_value=3.0, value=(0.0+3.0)/2, step=1.0)
   submitted = st.form_submit_button("予測")

まずはtitleというメソッドにより「アヤメ品種予測フォーム」というタイトルを生成します。そして、formというメソッドによりフォームを作成します。続いて、フォームの要素としてwriteというメソッドにより補足文を作成します。そして、number_inputというメソッドにより数値入力欄、form_submit_buttonというメソッドによりフォームのサブミットボタンを用意します。数値入力欄は4項目を用意し、それぞれにラベル、下限(min_value)・上限(max_value)、初期値(value)などを設定します。ここまでで、フォームを実現します。続いて、予測結果の取得部分の作成について紹介します。

if submitted:
   st.write("## 予測結果")
   st.write("### 入力")
   input_df = pd.DataFrame(
       {
           "sepal length (cm)": sepal_length,
           "sepal width (cm)": sepal_width,
           "petal length (cm)": petal_length,
           "petal width (cm)": petal_width
       },
       index=["入力値"])
    st.write(input_df)

まず、先ほどのサブミットボタンの返り値であるsubmittedという変数に基づく条件分岐により、サブミットボタンを押した後に表示させる内容を用意します。そこで、いくつかの文字列を表示させます。また、入力された内容を整理したデータフレームも表示させます。先ほどのコードにより、サブミット後の出力を実現します。続いて、予測結果の出力部分を作成します。

   st.write("### 出力")
   pred_df = pd.DataFrame({
       "target_name": iris.target_names.tolist(),
       "probability": model.predict_proba(input_df)[0].tolist(),
   })
   target_name = pred_df.sort_values(
       "probability", ascending=False)["target_name"].tolist()[0]
   st.write(target_name)

まずは機械学習モデルに与えるデータの整理をし、予測結果として、アヤメの種類の名称を変数(target_name)に格納します。そしてこのtarget_nameを表示させます。このコードによってこの予測結果の出力を表示させることができます。

このようにウェブアプリケーションおよびMVPを実現します。そのような便利なstreamlitでしたが、MVP開発を望む前に把握したい事を整理します。元のコードとstreamlitの導入によって実現したMVPが成り立ちます。この時に気になるのが「streamlitの導入コストはどれだけか?」ということです。ここでの導入コストは実装のための学習・保守性などについて、つまり、「簡単さ」と「コード量」です。以上より、streamlitの導入コストを確認するために、「簡単さ」と「コード量」と言う観点で、先ほどのコードを見直します。ウェブアプリケーションを実現するために使ったstreamlitのメソッドについて以下に示します。

メソッド 振る舞い 論理ステップ数
title タイトルの表示 1
form フォームの作成 1
number_input フォーム内の数値入力欄の作成 4
form_submit_button フォームのサブミットボタンの作成(返り値によりサブミット後の動作の指定が可能) 2
write 文字列やデータフレームの表示 6

これらより、先ほどのウェブアプリケーションを実現するために記述していたコードは、どれもメソッドに対する振る舞いがわかりやすく、簡単だと思われます。また、メソッドは5種、論理ステップ数は14件でした。つまり、分析・検証のために記述した元のコードに加えて、簡単かつ多くないコードによるMVPの実現が期待されます。

streamlitのまとめです。MVP について説明しました。これは、ユーザーに必要最小限の価値を提供できるプロダクトであり、提供しようとしている価値の評価に有用です。そのようなMVPの開発に有用となる必要最小限のウェブアプリケーションを簡単に実現するstreamlitを紹介しました。これは、ウェブアプリケーション(特にUI)の開発を簡単に実現するライブラリです。特に機械学習などを扱うような大規模で複雑な開発におけるMVPの開発に有用です。

本記事のまとめ

最後に本記事のまとめをもって締めます。まずPython による開発をアップデートするライブラリについてお伝えしました。背景として、開発における理想と現実のギャップの解消のために開発プロセスを改善すると、良いことをお伝えしました。そこで本記事では「開発プロセスを改善つまり、開発をアップデートする有用なライブラリを紹介する」と説明しました。大きく4つのライブラリを紹介しました。まずは、pydanticという「モデルの定義に基づくバリデーションを実現」するライブラリを紹介しました。次に、panderaという「スキーマの定義に基づくデータフレームのバリデーションを実現」するライブラリを紹介しました。また、hypothesisという「入出力に関するプロパティの定義に基づくProperty-based testingを実現」するライブラリを紹介しました。最後に、streamlitという「必要最小限のウェブアプリケーションを簡単に実現」するライブラリを紹介しました。是非これらライブラリを使ってPythonによる開発をアップデートしてください。

アソシエーションルールマイニングに基づく推薦を民主化するライブラリ「AutoARM」をリリースするまでの記録

はじめに

先日、アソシエーションルールマイニングに基づく推薦を民主化するライブラリ「AutoARM」をリリースしました。AutoARMはPythonで実装されており、PyPIで公開されています。

pypi.org

またオープンソースソフトウェア(OSS)としてGitHubで公開されています。

github.com

ゼロからアイデアを生み出したことからリリースするところまででさまざまな経験をしました。そこで、さまざまな学びがありました。本記事はAutoARMをリリースするまでの記録です。

開発に至る動機

AutoARMの開発に至る動機は3つあります。

“アソシエーションルールマイニングに基づく推薦”の提案

開発に着手する直前、「今こそ“アソシエーションルールマイニングに基づく推薦”が活きる時代なんじゃないか?」と思っていたことです。詳細については以下のブログを読んでください。

daikikatsuragawa.hatenablog.com

簡単にまとめると以下の点で改めて有用な手法だと思っています。

  • 推薦の根拠を説明可能
  • 推薦を実施したい相手に紐づく情報がなくても推薦可能

そして、上記2点は、データ提供・活用が実施されていないサービスに対して有効だと考えられます。そして、日本におけるデータ提供・活用をブレイクスルーするひとつのキッカケになるのではないかと期待しています。

また、ライブラリになっていた場合、プライベートにおける取り組みではあるものの、現在所属している組織でも簡単に再利用が可能になります。それゆえ、現在所属している組織における新規サービス・機能の提案の火種になることも期待していました。

過去の自分(=未来の誰か)の支援

学生時代、利用状況、推薦に関する研究をしていました。そこでアソシエーションルールマイニングに基づく推薦を実装していました。

https://ieeexplore.ieee.org/document/8445832ieeexplore.ieee.org

実は当時、実装がとても苦手で、比較的多くの時間をかけて保守の手間を無視する危なっかしいスクリプトを書いていました。というのも、アソシエーションルールマイニングに基づく推薦ってライブラリとして実装されていなかった(もしくは見つからなかった)のです。

もっと前にも似たようなことがありました。テーブルデータを用意した状態で、「こんな手法で予測したい」という方針は決まっているものの、スクリプトを書けないが故に手が止まってしまうということです。この日は状況共有の機会の前日だったこともあり、すぐにでも実現したいと思い、詳しい同期にスクリプトを書いてもらいました。すると一瞬でやりたいことが実現できました。この出来事をきっかけに学術研究、特に機械学習やデータ分析を必要とするものにおいて、技術がなく実現できない、提案できないアイデアがあるんじゃないかと思っていました。ただ近年、AutoMLが提案されており、機械学習という技術は民主化されています。これにより、上述した過去の自分が助かります。過去の自分の悩みは、未来の自分や誰かの悩みです。AutoMLにより未来の誰かの問題の解決に進んでくのではないかと思っています。

AutoML開発の動機についても技術にしてもとても共感していました。そんな中、“アソシエーションルールマイニングに基づく推薦”って実装されていない、つまり民主化されていないと思いました。個人的に有用な手法だと思っているため、過去の自分(=未来の誰か)のためにも実装し、誰もが利用できる状態にすることが望ましい状態と思いました。

(オーナーとして)OSSの開発

ソフトウェアエンジニアとして、意味のあるOSSを、自分がオーナーとして開発したいと思っていました。下記より既にOSSはリリースしたことがあるのですが、やはり、自分が貢献したいと思っているデータ分析、機械学習に関して、取り組みたいと思いました。

daikikatsuragawa.hatenablog.com

とにかく、ひとつを作りきることによって得られる経験値の大きさを期待していたため、単純にやってみたかったということがあります。OSSのスタンスについてもとても共感しています。完璧なものを開発しきるというよりは、「やりたいことの提示」を一番の目的としたいと思いました。自分よりも素晴らしいソフトウェアエンジニアが世界中にいることもあり、自分の思いに共感してくれた人が何かを直してくれたら、それがOSSのあるべき姿なんじゃないかと思ったためです。そのため、Minimum Viable Product(MVP)の考えに基づき、必要最小限の実装で、体験・価値を実現したいと思いました。このような思いを持ってOSS、特にPythonのライブラリを開発したいと思いました。

ライブラリの内容の設定

上述した動機に基づき、「アソシエーションルールマイニングに基づく推薦を民主化する」といったテーマでライブラリを開発しようと考えました。そこで、既存ライブラリを調査し、以下のような内容を定めました。

  • アソシエーションルールマイニングに基づく推薦に基づく過程を実装
    • テーブルデータの入力
    • 頻出パターンマイニング
    • アソシエーションルールマイニング
    • ルールに基づく推薦
  • 過程が首尾一貫しており誰でも簡単に利用可能
    • 参考とするインタフェースはAutoGluon*1

既存ライブラリに対する新規性は以下2点です。

  • アソシエーションルールマイニングに基づく推薦を対象
  • (アソシエーションルールのライブラリに対して)推薦までを実装

以上より、開発に着手しました。

推薦の流れ

新規性としてもアピールしていた「推薦」の流れを紹介します。MVPに基づき、最もシンプルな方法はこれだなと思う方法を実装しました。インプットは推薦対象の現状のアイテムリストと、事前に出力したルール群、推薦の基準とするメトリック(信頼度またはリフト)です。アウトプットは推薦の参考になるルールN件です。流れを以下に示します。

  • ルール群の結論部を分割(多:1のルールに)
  • 入力したアイテムリストと一致する条件部を持つルールを特定
  • 入力したアイテムリストと結論部が一致するルールを除外
    • この手順はスキップも可能
  • メトリックとして指定された信頼度またはリフトでルールを並び替え
  • 上位のルールに対して結論部が重複するルールを除外
  • 指定されたサイズ(N件)のルールを出力

詳細や実装についてはREADMEやソースコードを見ていただけると幸いです。

これにより、AutoARMは推薦の参考となるルールを出力します。ミソはアイテムではなく、ルール自体を出力することです。つまり、そのアイテムを推薦する根拠を残しています。これにより、根拠を説明しつつアイテムを推薦するため、相手の行動を促す推薦サービスが実現されます。

AutoARMの紹介

上記のような過程を経て開発を進めてAutoARMが完成しました。ざっくりと紹介します。

まず始めにデータを用意しておきます。サンプルとして適当なものを生成しています。

import pandas as pd

sample_dataset = {
    'transaction_id':
    [1, 1, 1, 2, 2, 3, 3, 3, 4, 4, 5, 5, 5, 6, 6, 6, 6, 7, 7],
    'item_id': [
        "X", "Y", "Z", "X", "B", "Y", "A", "C", "A", "C", "X", "Y", "Z",
        "X", "Y", "B", "A", "X", "B"
    ],
}
df = pd.DataFrame.from_dict(sample_dataset)

つまりこのようなテーブルデータが必要です。transaction_id列、item_id列`にあたる列さえあれば他に何かあっても問題はありません。列名は後でしているため、異なっていても問題はありません。

transaction_id item_id
1 X
1 Y
1 Z
2 X
2 B
... ...
7 X
7 B

ここからAutoARMについてです。まずはインストールが必要です。Pypiで公開されているため、以下でインストールが可能です。

pip install autoarm

以下により、アソシエーションルールマイニングに基づく推薦を実現するオブジェクトを生成可能です。import文を除くと、4行です。

from autoarm import AssociationRules, Dataset, FrequentItemsets, Recommender

dataset = Dataset(df, "transaction_id", "item_id")
frequent_itemsets = FrequentItemsets(dataset, min_support=0.01)
association_rules = AssociationRules(frequent_itemsets,
                                     metric="confidence",
                                     min_threshold=0.1)
recommender = Recommender(association_rules)

以下により、推薦が可能です。

items = ["X", "Y"]
recommend_rules = recommender.recommend(items, n=3, metric="confidence")
recommend_rules

以下の表が出力されます。

rank antecedents consequents support confidence lift
1 (X, Y) (Z) 0.285714 0.666667 2.333333
2 (X) (B) 0.428571 0.600000 1.400000
3 (Y) (A) 0.285714 0.500000 1.166667

例えば、この出力に基づいて「既にあなたが購入を検討しているXとYを購入した人の66%がZも購入しています。Zを購入してみてはどうでしょうか?」といった説明を加えた推薦が実現されます。また、XとYの購入を検討している推薦を実施したい相手に紐づく情報がなくてもこのような推薦が実現されます。良いですね。

以上より、簡単にアソシエーションルールマイニングに基づく推薦が実現されます。

今後の展望

正直なことを言うと、“アソシエーションルールマイニングに基づく推薦を民主化”するためにまだまだ追加することが望ましい機能があると思っています。例えば以下です。

  • さまざまな形式の入力データの対応
  • パラメータの自動調整
  • アソシエーションルールマイニングに基づく別の推薦手法の実装

そして、OSSとしてもっとこんな状態にしたかったと思っていることがあります。例えば以下です。

  • Poetryによるプロジェクト管理
  • GitHub Actionsの有効活用
  • 値オブジェクト*2の実装

自分でガンガン開発してしまうのもいいのですが、せっかくGitHubで公開して、指針もあるため、プルリクエストを期待してひとまず手を動かすのは止めようかと思っています。特に、自分にはレビューしてくれる人がいないため、自らバグを混入してしまう可能性もあるためです。また、もっとやりたいこともあるため、世界のソフトウェアエンジニアに任せてみたいと言うこともあります。

そのため、ひとまず開発自体は小休止して、どのようにサービスに組み込むのかなどについて注力して考えようと思います。

最近のお寿司屋さん、タッチパネルでの注文が浸透していますよね。こことかで活躍しそうだなとか妄想しています。

おわりに

アソシエーションルールマイニングに基づく推薦を民主化するライブラリ「AutoARM」をリリースするまでの記録を紹介しました。是非とも使ってください!フィードバックください!コントリビュートしてください!スターください!

おまけ

本文に書くほどではないが、遺しておくべきだと感じた内容について、サクサクと記録します。

  • テストはとても大切(ユニットテスト〜運用テスト)
    • ユニットテストに何度も救われた
    • 運用テストに何度も救われた
    • しかしテスト設計はまだまだ未熟
  • AIソフトウェアのテストは非常に難しい
    • パフォーマンスの担保
    • 「AIソフトウェアのテスト」が参考になる?(めどがついたため未読)

  • 現実的な利用状況に適した速度およびアルゴリズム
    • プロトタイプ作成時はすごく遅かった(レコメンドに数分…)
    • 問題を解決するために別のライブラリ「df4loop」も誕生した

pypi.org

  • 初めてのリリース(Pypiへの公開)はすごく緊張する
    • 10分ほど精神を統一したのちヤケになって「ポチッ!」
    • 多分経験値は大きい
  • 社内LT会で少しだけ紹介した
    • 有識者・初学者それぞれから良いフィードバックが得られました
    • GUIで見せたかった…
    • サービスのイメージまで伝えたかった…
  • “サクっと”API作れるようになりたい
    • 一回テンプレートみたいなものを作るか…
    • 欲を言うとDocker、Kubernetes
  • “サクっと”ウェブアプリケーションを作れるようになりたい
    • Django
    • Flask?
    • 一回テンプレートみたいなものを作るか…(再)
    • 欲を言うとDocker、Kubernetes…(再)
  • 開発環境はほとんどGitpod+Colab!

*1:Amazon Web Services - LabsのAutoMLライブラリgithub.com

*2:ドメイン駆動設計を担う要素のひとつ