pydantic系の処理を厳密にする

[Hiroshiba]

内容

型を便利に扱えるpydanticをよく使っていますが、デフォルトの状態だと結構扱いが特殊なことに気づきました。
デフォルトの状態をより良くすることで、ミスを防ぎやすくなると思われます。

このissueはpydanticをより使いやすくするための手順をメモしたものです。

Pros 良くなる点

よりコードが書きやすくなる。（というよりミスしなくなる）

実現方法

1. pydanticをv2にする
   • v1から挙動がいくつか変わって分かりやすくなってる
2. いろいろ良い感じの共通BaseModelを作って、全てから依存する
   • 例えばデフォルトでは再代入時に型検査をしてくれないので、validate_assignmentをTrueにする
   • 他にもstrictなど便利そうなものは設定しても良さそう
   • 配置するならmodel/base.pyとか？
3. 開発モードと製品モードを切り替えて、製品モードの時はより軽い状態にする
   • 2で設定したものはおそらくある程度処理が重くなってしまうので、製品モードの時はもっと検査を緩めて軽くすると良さそう

その他

（本当は1個1個やりたいのですが、ちょっと他のことやらないといけないので、とりあえずメモしてみました。どなたか進めていただけると。。。）

[tarepan]

ref #262 (comment)

[tarepan]

pydantic に関連する様々な検討と実装がおこなわれ、issue の課題は大方解決しました。

@Hiroshiba
本 issue は resolve につき close 可能そうです。

[Hiroshiba]

まだ実現方法の2と3が未達かもです！

結構実装も変わったので、そもそもやる・やらないを議論しても良いかも。
個人的には、再代入時に型エラーが出ないのはいつかanyを代入したときとかに問題になりそうだな〜とちょっとだけ思いました。
strictもミスに気づけるのが早くなりそう…？

[github-actions]

本 Issue は直近 30 日間で活動がありません。今後の方針について VOICEVOX チームによる再検討がおこなわれる予定です。

[Hiroshiba]

pydanticデフォルトのBaseModelを使う形だと若干不安ではあるものの、大多数において問題は無いとは思われます。
若干不安な理由は、デフォルトのだと再代入のときに型検査をしてくれないなど、意図しない挙動がちらほらあるためです。

とはいえissueにするほどなのかどうかが判断むずかしいです。
少なくとも今のissueの形だと、細分化されたタスクのうち最初のが終わっている少しわかりにくい状態なので、小分けにしてissueを作ったほうが良いかもです。

@tarepan さん的にどうでしょう･･･？

[sabonerune]

試していないのでもしかしたら違うかもしれませんがstrictを有効化した場合APIからの入力データの検証が厳しくなるかもしれません。
現状のエンジンで試したところJSONの数値を文字列で渡すと自動的に数値に変換して動作するという挙動がありました。

もしstrictを常時有効化する場合、少なくともアナウンスが必要な変更になってしまうかもしれません。
またstrictを開発時とリリースに動作を切り替えるのはPydanticのValidationの挙動を変えてしまうのでリリース時のみ発生するバグを生む原因になるかもしれません。

現状でstrictを有効化するのはVOICEVOX内部で扱うデータのみにするべきかもしれません。

[Hiroshiba]

あ〜なるほどです！！　たしかに破壊的変更になってしまうかもしれませんね･･･。
最初からstrictであればそちらのほうが良いけど、わざわざ変えるほどかというと･･･。

現状でstrictを有効化するのはVOICEVOX内部で扱うデータのみにするべきかもしれません。

strict等に頼りたい理由はコーディングミスを減らすという意図だったのですが、そういえば内部で扱うデータはpydanticではなくdataclassを使うようになってきているので効果は薄いかもしれません。

うーん、となるとstrictやついでにvalidate_assignmentもまあなくても良い････かなぁ。
何かしらのミスが起こったら再考という形でも良いのかなと思えてきました！

[github-actions]

本 Issue は直近 30 日間で活動がありません。今後の方針について VOICEVOX チームによる再検討がおこなわれる予定です。