wono

Svelte/npm界隈では「Webアプリ（npm create svelte）」と「ライブラリ（npm init）」で初期化コマンドとフォルダ構造が明確に分かれています。しかし、Pythonでは「ゲームのようなアプリ」も「ライブラリ」も、基本的に同じフォルダ構造（パッケージ構造）で作ります。

【理由】 Pythonの import には 「実行したスクリプトがあるディレクトリを、自動的にモジュール検索パス（sys.path）の先頭に追加する」 という仕様があります。もしソースコードをルート直下に置くと、config.py などの一般的な名前が標準ライブラリやサードパーティ製ライブラリと衝突し、意図しないファイルが読み込まれるバグが発生します。これを防ぐため、Pythonでは 「ソースコードを src/ の中に閉じ込め、パッケージ（箱）として厳格に管理する」 のが現代の標準（最適解）となっています。

2. フォルダ構成の2大パターンと初期化コマンド

Pythonのプロジェクトには、目的に応じて2つのパターンがあります。

パターンA：`src` レイアウト（本格的アプリ・ライブラリの標準）

ソースコードを src/ に隔離し、名前衝突を物理的に防ぐ構造。ゲームやWebアプリなど、まともな規模の開発ではこれが唯一の最適解です。

初期化コマンド: uv init <プロジェクト名>
Web界隈でのイメージ: Vite/SvelteKit の src/ 構造や、npmパッケージの標準構造。

game-lab/
├── .venv/                     # 仮想環境 (node_modules)
├── src/
│   └── game_lab/              # パッケージ本体 (Svelteの src/)
│       ├── __init__.py        # パッケージのエントリーポイント (index.ts)
│       ├── __main__.py        # アプリ起動ファイル (main.ts)
│       ├── core/              # ゲームエンジン等 (lib/store)
│       │   ── __init__.py
│       └── entities/          # キャラクター等 (components)
│           └── __init__.py
├── tests/                     # テストコード (Vitest/Jest)
├── pyproject.toml             # 設定・依存関係 (package.json)
└── uv.lock                    # ロックファイル (package-lock.json)

パターンB：フラットレイアウト（簡易スクリプト向け）

src/ を使わず、ルート直下にスクリプトを配置する構造。ファイル数が少なく、配布やテストを考慮しない使い捨てコード向けです。

初期化コマンド: uv init --app <プロジェクト名>
Web界隈でのイメージ: 単一の index.js や script.js を置くだけの簡易プロジェクト。

my-script/
├── .venv/
├── main.py                # ルート直下のエントリーポイント
├── config.py              # 設定ファイル
├── utils/                 # 補助モジュール (サブパッケージ)
│   └── __init__.py
├── pyproject.toml
└── uv.lock

3. `init.py` の正体（なぜフォルダごとに置くのか）

パターンA・Bを問わず、「import 文で指定するディレクトリ（サブパッケージ）」には必ず __init__.py を配置します。

パッケージのマーカー: 「このディレクトリは意図的なパッケージである」ことをPythonおよび開発ツール（mypy, pytest等）に明示し、予期せぬ挙動を防ぎます。
APIの集約 (Barrel Export): Svelteの index.ts と同様の役割です。__init__.py 内で from .module import Class を行うことで、利用側は内部のファイル分割を知らずに from package import Class と簡潔に記述できます。

4. ゲーム（アプリ）の開発フロー（パターンAの場合）

「ゲームはライブラリではない」という認識は妥当ですが、Pythonの生態系において「テストの安定性・インポートの確実性」を担保する構造は、ライブラリと本格的アプリで共通しています。

ステップ1: 初期化と依存関係の追加

uv init game-lab
cd game-lab
uv add pygame  # npm install に相当

ステップ2: エントリーポイントの作成

アプリとして起動するための「入り口」を作ります。

# src/game_lab/__main__.py を新規作成
from game_lab import main

if __name__ == "__main__":
    main()

※ __main__.py は、Pythonが「このパッケージは直接実行できるアプリですよ」と認識する特別なファイルです。

ステップ3: アプリの実行（重要）

python src/game_lab/__main__.py と直接打つのではなく、uv run を通じてモジュールとして実行するのが正解です。

uv run python -m game_lab

※ -m は「モジュールとして実行する」という意味です。これにより、src/ の中身が正しくパッケージとして読み込まれ、import のパスがズレるのを防ぎます。

ステップ4: テストの実行

uv add --dev pytest
uv run pytest

srcレイアウトにしているおかげで、テストコードから from game_lab.entities import Player と書いた時、確実にsrc/内のコードを参照できます。

5. 結論

Pythonでは「アプリ」も「ライブラリ」も同じ src レイアウトで作るのが標準。
uv init は、その標準的な src レイアウト（pyproject.toml + src/）を生成するコマンド。
アプリとして動かすには、__main__.py を作り、uv run python -m プロジェクト名 で実行する。
この構造は「インポート時のバグを防ぎ、テストや配布をスムーズにする」ためのPython特有の最適解。

10/29/2026, 1 engagement

でもおひるだ！ごごにしよう

10/29/2026

みてほしい資料できたけど隣の人いそがしいかなーいつみせようかなーとおもって席たったついでに画面ちらっとみたらpythonしてた

10/29/2026

をあー

10/29/2026

game-lab/ ├── .venv/ # 仮想環境 (node_modules) ├── src/ │ └── game_lab/ # パッケージ本体 (Svelteの src/) │ ├── __init__.py # パッケージのエントリーポイント (index.ts) │ ├── __main__.py # アプリ起動ファイル (main.ts) │ ├── core/ # ゲームエンジン等 (lib/store) │ │ ── __init__.py │ └── entities/ # キャラクター等 (components) │ └── __init__.py ├── tests/ # テストコード (Vitest/Jest) ├── pyproject.toml # 設定・依存関係 (package.json) └── uv.lock # ロックファイル (package-lock.json)

my-script/ ├── .venv/ ├── main.py # ルート直下のエントリーポイント ├── config.py # 設定ファイル ├── utils/ # 補助モジュール (サブパッケージ) │ └── __init__.py ├── pyproject.toml └── uv.lock

wono

フリマ用レジ・在庫管理システム　要件（iPad1台・1人運用・PWA／ネイティブ併記）

本日の知見まとめ

ローカルLLMへの道

1. Pythonの根本事情（Web界隈との決定的な違い）

2. フォルダ構成の2大パターンと初期化コマンド

パターンA：`src` レイアウト（本格的アプリ・ライブラリの標準）

パターンB：フラットレイアウト（簡易スクリプト向け）

3. `init.py` の正体（なぜフォルダごとに置くのか）

4. ゲーム（アプリ）の開発フロー（パターンAの場合）

ステップ1: 初期化と依存関係の追加

ステップ2: エントリーポイントの作成

ステップ3: アプリの実行（重要）

ステップ4: テストの実行

5. 結論

wono

フリマ用レジ・在庫管理システム　要件（iPad1台・1人運用・PWA／ネイティブ併記）

本日の知見まとめ

ローカルLLMへの道

1. Pythonの根本事情（Web界隈との決定的な違い）

2. フォルダ構成の2大パターンと初期化コマンド

パターンA：`src` レイアウト（本格的アプリ・ライブラリの標準）

パターンB：フラットレイアウト（簡易スクリプト向け）

3. `init.py` の正体（なぜフォルダごとに置くのか）

4. ゲーム（アプリ）の開発フロー（パターンAの場合）

ステップ1: 初期化と依存関係の追加

ステップ2: エントリーポイントの作成

ステップ3: アプリの実行（重要）

ステップ4: テストの実行

5. 結論

wono

フリマ用レジ・在庫管理システム 要件（iPad1台・1人運用・PWA／ネイティブ併記）

本日の知見まとめ

ローカルLLMへの道

1. Pythonの根本事情（Web界隈との決定的な違い）

2. フォルダ構成の2大パターンと初期化コマンド

パターンA：src レイアウト（本格的アプリ・ライブラリの標準）

パターンB：フラットレイアウト（簡易スクリプト向け）

3. __init__.py の正体（なぜフォルダごとに置くのか）

4. ゲーム（アプリ）の開発フロー（パターンAの場合）

ステップ1: 初期化と依存関係の追加

ステップ2: エントリーポイントの作成

ステップ3: アプリの実行（重要）

ステップ4: テストの実行

5. 結論

wono

フリマ用レジ・在庫管理システム 要件（iPad1台・1人運用・PWA／ネイティブ併記）

本日の知見まとめ

ローカルLLMへの道

1. Pythonの根本事情（Web界隈との決定的な違い）

2. フォルダ構成の2大パターンと初期化コマンド

パターンA：src レイアウト（本格的アプリ・ライブラリの標準）

パターンB：フラットレイアウト（簡易スクリプト向け）

3. __init__.py の正体（なぜフォルダごとに置くのか）

4. ゲーム（アプリ）の開発フロー（パターンAの場合）

ステップ1: 初期化と依存関係の追加

ステップ2: エントリーポイントの作成

ステップ3: アプリの実行（重要）

ステップ4: テストの実行

5. 結論

フリマ用レジ・在庫管理システム　要件（iPad1台・1人運用・PWA／ネイティブ併記）

パターンA：`src` レイアウト（本格的アプリ・ライブラリの標準）

3. `init.py` の正体（なぜフォルダごとに置くのか）

フリマ用レジ・在庫管理システム　要件（iPad1台・1人運用・PWA／ネイティブ併記）

パターンA：`src` レイアウト（本格的アプリ・ライブラリの標準）

3. `init.py` の正体（なぜフォルダごとに置くのか）