CPU数(長い文章)+4、と書いてあるのでそれがまとまりだとわかりにくいと思います。

(os.process_cpu_count()が返す)実行環境のCPU数+4と32のどちらか

だと読みやすいかな

この表現ちょっとわかりにくいかなと思いました。

buffersizeが指定されると、その数のプロセスやスレッドなどがスケジュールされ、それ以外は待ちとなる、ということですよね。

「未取得結果の最大件数」という表現がわかりにくいなと思いました

や

箇条書きで体言止めと、だであるが混ざっているので、どちらかに統一したい派

ここまでの手順を再実行すると多分この結果は得られないはず。手前で環境作り直すとかした方がいいかも?

依存ライブラリも一緒に削除されているのがポイントかなと

uv lockコマンド

こっちはまだ依存関係という言葉が残っている。タイトルと表現を合わせたい

ここはuv の節なので、「uvで」はなくてもいいかなと思った。他も同様

インストール可能な一覧とインストールされていたらその場所を出力している

インストール可能なPythonの一覧を出力する。が正しいです

List the available Python installations

uv pythonがない

README.mdも説明した方が良いのでは

ディレクトリもあるので「名前」としたい

2回目は冗長なので「ファイル群」とかでよいかと

本書で紹介するuvのコマンド

でいいかな。主なというよりはこの書籍で紹介するものを列挙していると思うので

最新版の0.9.17

addは追加するだけどremoveはアンインストールするなので表現が揃っていない。 追加/削除 or インストール/アンインストールに揃えて欲しい

が

の方がいいかなー

uvx とバッククォートで囲みたい。以下同様

外部パッケージによって提供されるツール

とか?

.pyはつけない派?

PEP 723で提案されたけどPyPA関連はのちのち変わっていくので、仕様としてはこちらを参照するのが適切です。

(PEPドキュメントの先頭にもそう書いてある)

https://packaging.python.org/en/latest/specifications/inline-script-metadata/#inline-script-metadata

外部

この手順よりは、新規にディレクトリ作成、uv init実行した後に、pyproject.toml, uv.lockだけコピーしてuv sync実行するみたいな手順がいいのではと思った。

実際のユースケースに合わせる

uv pip installした場合はuv addと違ってpyproject.tomlとかuv.lockが更新されないということを書いた方がいいかなぁ

名を

pyproject.tomlの設定を見て、今のuv.lockファイルに存在するパッケージのままか新しいバージョンが存在するかを調べる。

みたいな意味合いだと思います。

あと、これってどっちかというと hoge>4.0.0 とかかいていて、hogeの最新バージョンがでているか(pip list -O)みたいな使い方がメインかなと思ったんですが、そうではない?

pyproject.tomlを書き換えたのはここで例として示しているために必要なだけど、本来はpyproject.toml書き換えたらuv syncの方を使うかなと思ったので(uv 素人なのではずしてたらすいません)

uv.lockファイル

トルでもいいかな(あってもいいけど)

uv lock

uv.lockファイル

uv.lockファイル

ハッシュの例はハッシュ値を省略しつつ1行くらいは載せて欲しいかな

てインストールします。 pyproject.tomlにはdevというセクション(?)が追加され~~

みたいな文章がほしい。

このときもpyproject.tomlの中は書き換えられるよ(ですよね?)とか説明があっていいと思う

依存関係というよりも、「さきほど追加したパッケージが」とかいう説明でよいのではないか

pipコマンドと同様に、とかあってもいいかも

PyPIからダウンロードしてインストールされていることとか触れて欲しい。

依存関係を管理するってちょっとイメージしにくいかなと思いました。

プロジェクトで使用するライブラリを管理する、とか?

コマンド実行後

一文が長いので「利用できます。」で一度切ってもいいかも

なにももう一つの方法なのか

仮想環境下のPythonを実行するもう一つの~

とか?

に

の方がいいかな

さっきとは異なるディレクトリに作ったと言うことですかね。手順で mkdir uv-example がないのでちょっと混乱するかも

では

◯◯な場合に仮想環境を再作成します。

みたいな用途にも触れてくれるとうれしいなと思った。

長いし、トルでも意味は通じるかなと

確認するメッセージが表示されます。

コマンドを

で

でよさそう

仮想環境を有効化した場合は、プロンプトにプロジェクト(ディレクトリ名)が表示されることにも言及して欲しい。

venvは作成したvenv名がプロンプトで表示されていたので

ここで段落を変えてもいいかな

typo: いません

手順にlsを入れるといいかなと。 venvの方にはあった

uvで作成する仮想環境は、基本的にvenvで作るやつと同じだよ、みたいな説明がほしいかな

.py は付けない?

Pythonプロジェクト

とか最初は書いておいた方がいいかなと

この手前に全体を俯瞰したいので、uvで提供しているコマンド一覧がほしい。

全部紹介しないなら、そのうち本書ではこれを紹介するよ、とか言ってほしい

これを紹介しているので、あえてバージョン指定してのインストールは教えなくてもいいかなと

これ必要な場合ってありますか?説明しなくてもいいかなと思った

pipはパッケージインストーラーであってマネージャーじゃないかなという意見

https://pip.pypa.io/en/stable/

あー、でもpipの方に「パッケージを管理する」って書いてるのか、じゃあこのままでいいかなぁ

nits: コメントでどういうチェックを有効にしたかかいてあるといいかも

起こり

したりすると

トル

日本語訳も併記して欲しい

これ、紹介しなくてもいいんじゃないかな。使いどころがなさそう

これはよくあるエラーなのか?

よくあるエラーだと上にあるTOMLDecodeErrorが出るから、それを見てちゃんと対処してね、っていう話が適切かなと思いました。

どっちかというと周辺知識よりかなと思いました

浮動小数点数

綴り間違い

とかちゃんと書いておきたい

ちょっと読みにくいかなと思いました。

PEP 680においても、以下の理由によりTOMLの読み込みのみで書き込みには対応しないことと記述してあります。

• ~~標準化が困難
• ~~設計が複雑
• ~~将来的~~安全

ライブラリ

外部ライブラリ

外部のライブラリ

バッククォートでかこんで欲しい

最初にコメントで「# さまざまなデータ型を定義」みたいな文があるといいかなと思いました

のみ

挙げられています。

最後までよんでPEPの話だと思ったので、この文の最初に

PEP 680中ではtomllibを標準ライブラリとする理由として~~~が挙げられています。

みたいに書いた方がいいかなと思いました。

でTOMLフォーマットを標準サポートすることは

とか

パッケージに関する情報を記述するpyproject.tomlの

とか?(ちょっと表現がふわっとしている&省略されているかなと思った

Python 3.11

サポートが連続するので言い換えたい。

プログラミング言語にTOMLファイルに対応したライブラリがあります。

とか

IMO: 真偽値の方が好み

結果が見にくいのでpprintしてほしい派

サンプルコードがちょっとわかりにくいかなと思いました。

基本的には必須で、任意のフィールドがあるときは NotRequired を指定する

逆に、ほとんど任意で一部必須の場合には、total=Falseを指定して、必須のフィールドにのみRequiredを指定する

だと思うので、この2つを分けて説明するのがいいと思います。

リンクがほしい

「本来の引数」というのが何を指しているのかがちょっとわからないなと思いました

TypedDictの方が使うことが多いと思うので、Anyの次でいいかなと思った

nits: まま、が連続するので冗長かな

「引数を維持したまま」で意味は通じそう

nits: 表記揺れ: デコレーター

この文章を5.16のコードの前に持っていく方がいいかなと思いました

リンクを入れて欲しい(脚注にURLが入るはず)

ここ、インデントした方がいいかも?

今後主流になるかは

くらいでいいのでは

以下は冗長なので省略でよさそう

これだと短すぎるので、なんかのリポジトリをまるっと型チェックとかする方がいいかなと思いました

このリンクがわかりにくいので、説明を書いて欲しいかな。

サンドボックスでexample.pyを◯◯した結果

みたいな

nits: 比較する、でいいかなと

VS Codeと書くのが正しいはず https://code.visualstudio.com/

nits: 体言止めと~~するがまざっているのでどっちかに統一がいかな

高速に動作 付ける機能

でよさそう

あとで比較対象にもなっているので、「型チェッカーにはmypy、pyrightなどがありますが、Pyrefryには◯◯な特徴があります」みたいな感じの文章があるといいなと思いました

MUST: 結果が書かれていないので追加する

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

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

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

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

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

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

文章の流れが唐突な感じがする。

あります。また、チェック、修正の両方ができるツールにRuffがあります。次節ではRuffについて解説します。

とか?

クラスのことも書くといいのでは

MUST: リンク先のドキュメントが内容が無いです。変わったっぽいのでURLを変えてください

ここからkey関数について追記した

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側の制限なんじゃないだろうか。

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

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 を示して上げた方がいいのでは。(手元で試すために

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

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

他にもある?