counts引数の説明を追加して欲しい

こっちの方がよく使うので、先にあってもいいかなって思いました

下の図ですが、figureにタイトルを文字列として書いてください。可能なら、顔図としてもヒストグラムの画像そのものを入れて欲しい「図：~~~」の部分の画像が不要

https://pyhack.slack.com/archives/G01CKBZ7J8J/p1762173838549059

「表：」はトルでOK 他も同様

seed関数も表7.6で説明して欲しいな

下の画像に画像タイトルまで含まれているので、タイトルはちゃんと文字として入れて欲しい

https://pyhack.slack.com/archives/G01CKBZ7J8J/p1762173838549059

これなんだ? 脚注かなんかのミスかな

今回uvを追加するのでまるっと削除でもいいかも。

nits: PowerShellだとバックスラッシュの方がいいかも?

nits: PowerShellの方が最近は一般的だから上の方がいいかな

これ、.gitignoreの中が「*」なので、venv以下は全部対象外になる、という説明だけでいいと思います。

以下のgitの手順はなくていいかなと(情報が多くて逆に読みにくい) 以下だけでいいのでは感

$ python3.14 -m venv env $ cat env/.gitignore *

SHOULD: これよく考えたらpipの制限ではなくて、Python側の制限なんじゃないだろうか。

contextパラメーターも説明を書いて欲しい

ここに追加するなら、from_numberメソッドの説明は文章でもしてほしいかな

このあたりもコメントでどういう数値を作っているか書いて欲しいかな。

ここコメントでfloatの精度によってこうなっちゃうよって説明して欲しい

ここか7.2.1に組み込み関数のroundを紹介して、偶数丸めであることを書いて欲しいかなと思った

https://docs.python.org/ja/3.14/library/functions.html#round

これ、見出しレベルが違うかも?

1.1.0

1.1.0

MUST: 表タイトル入れてください

もうちょっと説明がほしいかな。 ハッシュがあるから改ざんに対応できるとか、さっきの課題にどう対応しているかの説明があるとうれしい。

でもそこまで書くとコラムとして書きすぎかなぁ。

の?

PEP 751だけだとわかりにくいし脚注もリンクだけなので、どういう内容のPEPかを最初に書いて欲しいです。

◯◯に関するPEP 751が、みたいな

数字の箇条書きであることに意味があるのかが気になった。 優先順位とかがないのであれば、数字なしの箇条書きがいいかなと思います

nits 最新版の4.0. でもいいかなと思った

これ、この手順通りにやるとpeppercornはインストール済みなので出力されなそう。ちょっと気になったのでコメントした

コメントになっていない

古いバージョンの話なのでトルでいいかなぁ

これ、見出しを設定して参照にしてください。(章、節番号変わるかもなので)

https://ryu22e-chap6.jissen-recipe2.pages.dev/sample/#id18

nits: weather みたいな変数名がいいな

ちょっとわかりにくいのでもうちょっと説明がほしいかな。

f-stringをネストしているというよりはf-stringの中の {} を入れ子にできるようになった。

以下の例では {value} が展開されて数値になって、そのあと :> の部分でフォーマットされている。

みたいな説明が欲しい。そうすれば逆にコード中のコメントは短くてよくなる

MAY: わかりやすさのために、通常の出力と=ありの両方があると親切かなと思いました

SHOULD これがあるので、最初の説明に「コメントも書けます」とか書いて欲しいかな

nits: 小数点もって書いてあるけど、別にzfillは先頭の+-以外は特別扱いしないので、そういう説明の方がいいかも

"abc".zfill(5) '00abc'

結構細かく変わってるんだなぁ

よさそう

良さそう

これも説明してほしい

これはよさそう

その手前で、そもそもTypedDictで必須とかオプションとか指定できるようになったので、この話をする必要があるかなと

typo: 用いる

ここももうちょっと具体的に書きたいですね。

Pythonで◯◯が管理しやすくなる、Pythonでコーディングする際に◯◯での△△の表示など型ヒントの恩恵が

みたいな具体的な文章にしてほしい

Pythonの辞書

の方がよいかと

JSONSchemaをPydanticのコードに変換

typo: パターン

トルでもよさそう

時間の変換に?カスタム〜〜

とか

公式ドキュメントへのリンクもあるとよさそう

Pydanticには単一の属性

nits: 時間の範囲を表記するとより親切だと思う

データ型を変更している、と言っていいのかが気になる。

Annotatedは直訳すると「注釈」なので

使うために

とか

ように、が連続してる

バッククォートに囲むとよさそう

場合は、2つの時間を

typo の

のフォーマットは、

2つのルールに分けた方がよさそう

• 時間のフォーマットはH:MMとする
• 時間は30分単位とする

文体を揃えるなら

するものがあります

ctxがなんの略か気になった

typo

を?

負の数使わなそうなので PositiveIntを使いたい派

これ、私も意味わかってなかったんですけど ... を指定すると必須だけどデフォルト値がないってこと、ですか?

聞き慣れない人が多いと思うので、公式ドキュメントを引用するとよいかと https://docs.python.org/ja/3.14/library/stdtypes.html#bltin-ellipsis-object

データ検証を具体的にするんでしょうか?

私のイメージとしては、データ形式(スキーマ)を具体的にするので、結果としてそのルールでデータ検証されている。というイメージです。

https://docs.pydantic.dev/latest/concepts/models/ にも以下の様に書いてある One of the primary ways of defining schema in Pydantic is via models. Models are simply classes which inherit from BaseModel and define fields as annotated attributes.

このようにPydanticは全データを検証して全部のデータをわかりやすく出してくれます。

みたいな文章が欲しい

Branchがどこから来るの? と思っちゃうので、別モジュールにして

from model import Branch

とか書いて欲しいかなと思った

このコードの説明を書いて欲しい。 例外が発生したら errors() メソッドでその詳細を出しているよ

みたいな

3人目のスタッフの

とか

これちょっとわかりにくいなと。

最初に例示していたときはPythonの辞書で、ここで書いているのはJSONってことですかね。 もうちょっとわかりやすく説明して欲しいです。もしくは最初からJSONということで話を始めた方がよいかと

横に長いので改行してほしいなぁ

さっきのdataclassは int | None だったけど変わっているのはんぜですか。統一して欲しい

次に繋げる文章がほしい

こういった◯◯といった課題に対して、Pydanticを使うと〜〜

みたいな

属性の

値の意味を表すコメントがあるとより親切かと

# スタッフ番号 みたいな

typo: 用いる

確認したりする

この文章を上に持っていってもいいのでは。

以下のように、値を確認〜〜

スタッフの辞書では、

かな

staffの中には各スタッフを表す辞書がリストの中に入っています。とか?

要素がリストの中に辞書が入っています。は日本語として意味がわからなかった

コードには全部キャプションを入れて欲しいです

```{code-block} python :caption: ここにキャプション

コード ```

Pydantic公式サイトへのリンクがほしい。

日本語がへんかなと。

参考にしてください。とか

MUST: コードが消えている。以下の部分でpythonのあとの改行が削除されている

```{code-block} python :caption: レストランを例にしたタスクのつながりのあるサンプル

以降も同様

nits: <>で囲んでりんくにしてください

記事公開時には終わってそう

タスクの可視化

が2回でてちょっと冗長かな

この節で伝えたいことあんまりわからないです。 _ではじまるやつをユーザーが使うことは想定しているのか?

リンク先は3.14だし、3.14版のドキュメントでよいと思う

Python 3.14

どういう動作をする想定のプログラムかを先に説明して欲しい。

基本的にコードにはキャプションを付けた方がいいかと

```{code-block} bash :caption: ほげほげ

$ ps ... ```

awaitグラフってなんですかー

鎖状って表現、一般的ですかね

これはなに? ps コマンドでも pstree コマンドでも同じ結果が出る? 違うっぽいな、こっちはpsコマンドの方の実行結果ですよね。

これ、実際に試すためのサンプルコード sample.py を示して上げた方がいいのでは。(手元で試すために

主語省略しがち。他の人が読むので福田さんの脳内はわからないです。

◯◯は以下の様にして実行します。

他にもある?

主語がない。

◯◯には大きく2つの

ウケる

URLのjaありとなしが混在しているのでどっちかに統一して欲しい

動作確認

なにが利用できないかをちゃんと書いて欲しい。

これらasyncioタスク可視化機能は利用できない

とか

既存のツールってなんですか?既存のツールを知らないです

あー、

python -m asyncio ps と asynncio ptree があるんですね。

ps/ptree のようなスラッシュ表記だとわからなかったので、ちゃんと分けて書いてほしいです。

あと、画像の文字が小さすぎるので、実行イメージはスクショじゃなくて、テキストとして入れてもらう方がいいかなぁ

~~関数

今回注目

今回筆者が注目

~~コマンドと

と書いて欲しい

print_call_graph() 関数、とか書いて欲しいかな

もうRC出てるので「追加される」でよいかと

おーーー、シーケンス図いいですねーーーー

ここの流れとかそれぞれ(Work Pools, Deployment等)の構成要素の役割がどうなっているか、もう一回まとめてほしいなと思いました。

このページの図がわかりやすいかは微妙だけど、それぞれが何の役割で、どうい依存関係なのかまとめてほしいなと思いました。

https://docs.prefect.io/v3/concepts/work-pools

これって1日1回の処理だから3回登録されている?それともどういうスケジュール設定でも3回?と疑問に思いました

確認される?

名前の入力を促されるのでは?

ここでは実行環境

を入力し?

だいぶ間をあけてこの用語が出てきたので、Work Poolの説明がもう一度ほしい

typo

August

localを選択して、◯◯な設定を~~

みたいな、この場合はこうするのでlocalを選んだよ、という説明が欲しい

まぁ、ローカルで実行するからだとは思うんだけど

このタスクってなにもしてなくてただログを出力するだけなので、ちょっと微妙だなって思いました。

ちゃんと処理があって、その処理内容を表すログを出して欲しい

get_run_logger()関数自体は使用するとロガーを取得するだけなので、

使用してロガーを取得し、そのロガーを使って出力します。

みたいな説明がより適切だと思います。

で◯◯を

なんの名前?

typo: では

これだけEvents(複数形)じゃないのはなんでなんですかね

前半3つだけカタカナ表記があるのが気になる。なぜ?

項目が6つと多いため表が窮屈で文章が改行されて読みにくいなと感じました。 箇条書きのネストにした方が読みやすくないかなぁ。でも、そうすると比較はしにくくなる。

表の中の文章を見た感じ、表に収めるためにだいぶ短くしているので、箇条書きにして普通に文章にした方がいいかも?

なんかここに+があるのは違和感があるので、日本語にして欲しいかなー

ワークフロー、の方がよいのでは

自動再実行があるのに、エラー通知があるのはなんか辺かなと

失敗時の処理を定義、とかなら意味が通じる

nits: 依存関係の管理

トルでも意味が通じそう

カタカナが連続して読みにくいので、以下みたいに書いて欲しい

ワークフロー・フレームワーク ワークフローのフレームワーク

公式サイトのタイトルでは「Pythonic, Modern Workflow Orchestration For Resilient Data Platforms」と書いてある。フレームワークという用語は出てこない

早い段階でPrefectの公式サイトへのリンクが欲しい

ことが

(なにと同列の「も」なのかわからない

ここで一旦まとめとして、自動的にAPI仕様書からデータを作ってテストを実行、それでバグを見つけて修正がきでたよ。

みたいなことを書いてもいいかなと思った

nits: 使い方は

nits: 読みがあってもいいかも

（スキーマンテシス）?

nits: API仕様 でよさそう

関数 https://github.com/schemathesis/schemathesis/blob/master/src/schemathesis/openapi/loaders.py#L84

さらっとやってみたって感じの内容なので、もし知見があるなら、実際にやってみてこんなことがあったよとか、ここが難しい、ここが便利みたいな、もうちょっと突っ込んだ内容があるとうれしいなと思いました。

max_examples() でテストケースの数を増やすことについても説明しても良さそう。ってかデフォルトだと何パターンテストするんだ?

https://schemathesis.readthedocs.io/en/stable/tutorials/pytest/#generating-more-test-cases

設定ファイルは別にCLIじゃなくてpytestでも使えるっぽい。 なので、設定ファイルでのカスタマイズみたいなのは別の見出しにした方がよさそう https://schemathesis.readthedocs.io/en/stable/tutorials/pytest/#configuration-file

設定できる項目は公式ドキュメントのここにあるよ、と説明して欲しい

どういう結果が出力されているのかを説明して欲しい。

これも、どこが書き換えられたのかわからない。

from_urlがfrom_asgiになっただけ?そうならそうだと説明して欲しい。

メソッドじゃなくて関数

https://github.com/schemathesis/schemathesis/blob/master/src/schemathesis/openapi/loaders.py#L22

一文が長いので、でした。で一度区切ってもよいかと

bは負の整数を受け入れてもよいと思います

以下のように、だと「どこを変更したの?」と探す必要があるので、

以下のように変数bの定義で〜〜Field(gt=0)を〜〜

のように、どのような変更をしたかを説明して欲しい。

気が利いてる！

ドキュメントを見るとGraphQLにも対応しているようです。 https://schemathesis.readthedocs.io/en/stable/

Web APIの、とか書いてくれた方がいいなと思いました。普通にPythonの関数をテストするデータとか作るのかなと思った

動いてる！！

まとめがMCP全般の話しかしていないけど、MCPサーバーやホストを自作する?みたいな観点でのまとめもあるといいなと思います。

ここで段落を分けてもいいかも

開き括弧がない

文が長いのでここで区切ってもいいかも。

起動します。その中で〜

みたいな

文が長いので2つに分けてもいいかも

この記事では〜にとどめています。 Claude〜多くのことを考慮する必要があります。

sseはさっきの説明になかったので気になる

します

コードのdocstringと合わせた方が良いかと

以下はOSの名前を取得するMCPサーバーです

3.12 or 3.13にしていない理由はありますか?なにか制限があるなら書いて欲しい

pip installでdotenv入れているので、追加しても良いのでは

この段階でシステム構成図がほしいです。

ローカルで何個かプログラムを立ち上げてー、とか?

後半にある「本記事で実装したMCP構成要素の対応関係」があればいいかなぁ。

「これからこういうシステム構成のものを作るよ、それぞれ今はここを作っているよ」とわかるように話を進めてもらえると、今どこをやっているのかが把握しやすくなると思います。

トル

一般的な用語ですか?漢字が連続しているなーと思った

この図はどこかから持ってきたものですか? あんまり図になっている意義を感じなかった。(箇条書きでもよさそう

あとPromptがtypoしてる

Server A B とLocal dara source、PostgreSQLも線でつないでほしい。 GitHubもロゴの下に「GitHub」と文字がほしい

SHOULD: ちょっと読みにくいので、こんな感じでも意図が伝わるかなと思います。

各LLMがそれぞれ外部ツールとの連携方法を

nits: 記事へのリンクが脚注にあるといいかも。これとか

https://gihyo.jp/article/2025/03/openai-mcp

nits: ちょっと読点が多いので、以下でもいいかなと

記述してLLMに伝えることで

ハードルを上げていくスタイル

コメントテスト

これらの公式サイトへのリンクがほしい。Flaskなども同様

関数名も index に揃えて欲しい派

FastAPIもhomeだったので、逆にFlaskの例の index() を home() にするのがよさそう

この説明いいですね。フレームワークでツールキットをラップして、より使いやすくしているということがわかる

では、○○をするとImmutable〜

なにかしないとオブジェクトは返ってこないと思うので。

このコードだと返ってきます、よりは

request.form にフォームをパースした○○オブジェクトが格納されています。

とか

HTTPユーティリティは規約に〜

とか主語があった方がいいかなと思いました

扱いの例

かな

これはあんまり賛同できないです。

結局Webフレームワーク全体としてどういう機能を提供しているか、を見ることになると思うので「Webツールキットがこの機能を提供している」とかは選択の判断材料にならないと思います。

Pyramidは人気か?と思うので「トル」でもいいかなと

親切

発音よりは「読み方」かな

ウィスギー派

読み方

トル

ルーティング例として似たようなコードになっている方がイメージしやすいと思います。

あと、ルーティングだけFlask/FastAPIとそれぞれのパターンを提示して詳細に説明しているけど、他と重みが違うのはなんでなのかは気になります。

ここだけ詳細に伝えたい意図はなんなのか(他は文章でさらっとしている

見出しレベルを下げた方が良い(ルーティングの中だと思うので)

これもコード例がほしいなー

PythonのオブジェクトでリクエストやレスポンスをWebツールキットの一種で処理するコード例がほしいなー

なんか図とかあるといいんですけどねーーー、低レイヤーはどの部分なのとか

とはいえ、どういう図がいいのかのイメージは湧いていない

トル or 的な

Webツールキットがどのような

なんの詳細?

主な、とはなにか

トルでも意味が通じそう

統合って書かなくてもいいのでは

これ、1つの列で、列のタイトルを Werkzeug / Flask とかにして、各行には「W / F / 拡張」とか書いた方がわかりやすいのではと思った

上でも説明しているので書かなくてよいのでは

Webツールキットが登場する

機能提供という文字が多いけどそんなに意味がないので、○とかにして、「○はそこで機能を提供している意味ですよ」とか説明したい。 拡張で提供も「拡張」とだけ書いて、拡張機能をインストールすることで~~みたいな説明を文章で書きたい

機能

下の表でも見出しで「機能」と書いている