Python 00：はじめに ― import はどこから来るのか

この本で解く6つの疑問

最初に、この本で答える疑問を並べておきます。図の6枚のカードが、それぞれ何章で解決するかの対応です。

図の色は、この本全体で役割を表します。黄は Python のコードとその実行、緑はファイル・フォルダ・ディスク、青はインターネット（PyPI・GitHub）、灰はあなたや JS の世界、白は pip・uv などの道具、赤は間違いや危険です。

どの答えも、よく見ると「どこに何があり、そのとき何が起きているか」という形をしています。Python の「なんとなく」は、ほとんどがこの2つを見ていないことから来ます。逆に言えば、置き場所と順番さえ見えれば、どれも驚くほど地味な仕組みです。

魔法に見える4行を、この本で1つずつ分解する

Python を使い始めると、意味を知らずに打つ「おまじない」がいくつも出てきます。代表的なのが図の4行です。

どれも、裏でやっていることは地味で具体的です。たとえば activate は、名前からは「何か特別なモードに入る」ように見えますが、実際にやっているのは文字列を1つ書き換えるだけです。それが分かっていれば、「activate し忘れたのに動いた」「activate したのに違う Python が動く」といった現象も、自分で説明できるようになります。

この本では、こうした1行が出てくるたびに、番号札の順に1段ずつ分解します。図の中で小包が動いたら、それが「いま何がどこからどこへ運ばれているか」です。

先取り①：import は、決まったフォルダの中を探すだけ

本編に入る前に、この本の答えを少しだけ先に見ておきます。舞台は図の2つの囲みです。左があなたのパソコン（緑）、右がインターネット（青）です。

最初は import requests です。main.py にこの1行があると、Python は「requests という名前のもの」を、パソコンの中の決まったフォルダから探します。見つかるのは、たとえば次のようなファイルです。

/Users/you/tenki/.venv/lib/python3.13/site-packages/requests/__init__.py

特別な形式ではありません。requests という名前のフォルダがあり、その中に __init__.py というただの Python のファイルがあるだけです。エディタで開けば、普通の Python のコードが読めます。Python はこのファイルを上から実行し、そこで定義された関数（get など）を requests.get として使えるようにします。

「どのフォルダを、どの順番で探すのか」「見つけた後に何が起きるのか」「なぜ2回 import しても1回しか実行されないのか」は、第8章で1段ずつ分解します。ここでは「import は、ディスク上のファイルを探して読むこと」とだけ覚えておいてください。

先取り②：pip install は、PyPI から落として置くだけ

では、先取り①の site-packages の中の requests フォルダは、誰がそこに置いたのでしょうか。答えは pip install requests です。

図の小包が、右の PyPI から左の site-packages へ運ばれていきます。PyPI（パイピーアイ、Python Package Index）は pypi.org にある、Python のライブラリの公開の置き場です。JS でいう npmjs.com にあたります。

pip install requests がやっていることを、ざっくり並べるとこうなります。

JS の npm install が node_modules に置くのと、発想は同じです。大きく違うのは「どこに置くか」の既定です。npm は今いるプロジェクトの中に置きますが、pip は既定で「その Python 全体」の site-packages に置きます。この違いが、Python で仮想環境（venv）を作る理由です（第11・12章）。

そして大事なのは、pip install と import は別々の仕事だということです。pip は置くだけで、読み込みはしません。import は探して読むだけで、ダウンロードはしません。「pip install したのに import できない」というよくある困りごとは、たいてい「置いた場所」と「探している場所」がずれていることが原因です。

先取り③：GitHub に上げるのは、コードと「一覧」だけ

自分のパソコンで tenki が動いたので、GitHub に上げて友だちにも使ってもらうことにします。このとき、何を上げればいいでしょうか。

答えは、あなたが書いたコードと、「このプロジェクトには requests が要る」と書いた一覧のファイルだけです。一覧のファイルとして、図では pyproject.toml を置いています。

ライブラリの本体を上げないのは、JS で node_modules/ を .gitignore に入れるのと全く同じ理由です。ライブラリは PyPI から誰でも取ってこられるので、同じものを GitHub にもう1つ置く必要はありません。それに .venv/ の中には、あなたのパソコンの場所（/Users/you/...）や、あなたの OS 用に作られたファイルが含まれていて、他人のパソコンにそのまま持っていっても動かないことがあります。

JS と見比べると、対応はこうです。

一覧の書き方、版の指定の仕方、ロックファイルの意味は第13章で扱います。

先取り④：受け取った人は、一覧を見て自分の手元で入れ直す

最後に、友だちの側です。図の右に「友だちのパソコン」が増えました。友だちの手元には、2本の道で物が届きます。

友だちは、まず GitHub からコードを取ってきます。この時点では、友だちの手元に requests はまだありません。そこで一覧（pyproject.toml）を読んで、自分の手元で requests を PyPI から入れ直します。これで、あなたと同じ環境が友だちのパソコンにもできます。

git clone https://github.com/you/tenki.git
cd tenki
uv sync          # 一覧どおりに .venv を作り、ライブラリを入れる
uv run python main.py

これは JS で git clone のあとに npm install するのと同じ流れです。Python でも、道具を uv にすれば uv sync の1行で済みます。uv は、Python を入れる・仮想環境を作る・ライブラリを入れる・版を記録する、を1つにまとめた、いまよく使われている道具です。この本では、まず標準の pip と venv で仕組みを見てから、uv を「同じことを速く・まとめてやる道具」として紹介します（第13章）。

さらに一歩進めると、tenki そのものをパッケージにして、友だちが pip install 一発で入れられるようにもできます（第14章）。

ライブラリは「あなたが呼ぶ」、フレームワークは「あなたを呼ぶ」

「ライブラリ」と「フレームワーク」は、どちらも他人が書いたコードです。置き場所も入れ方も同じで、どちらも pip で入り、site-packages に置かれます。では何が違うのでしょうか。

違いは、どちらが主導権を持つかです。

図の左では、あなたのコードが requests.get(url) と呼んでいます。いつ呼ぶかを決めるのはあなたです。右では向きが逆です。あなたは「/weather にリクエストが来たら、この関数を使って」と FastAPI に登録しておくだけで、実際にその関数を呼ぶのは FastAPI です。

この「呼ぶ向きが逆になる」ことを制御の反転（Inversion of Control）と呼び、「こちらから電話しないで、こちらがかけるから（Don't call us, we'll call you）」という言い回しで説明されることもあります。

JS で Express を使ったことがあれば、app.get("/", (req, res) => ...) と書いた関数を自分で呼んだことは一度も無いはずです。あれと同じです。第10章でこの違いを詳しく見て、第17章では実際に tenki を FastAPI の Web API にします。

JS の言葉と Python の言葉の対応表

Python の世界の道具は、ほとんどに「JS でいうアレ」があります。最初に対応を知っておくと、新しい名前が出てきても怯えずにすみます。

JS の側の仕組みがふわっとしていても大丈夫です。たとえば「package.json と package-lock.json の違い」は、第13章で Python のものと並べて、JS の側も一言ずつ説明し直します。

対応表を見て「なんだ、同じじゃないか」と思えたなら、それで正解です。考え方の多くは JS と共通で、違うのは名前と、いくつかの既定の振る舞いです。その「違う既定」が、次に見る3つです。

似ているけれど、つまずく3つの違い

JS から来た人が Python でつまずく場所は、だいたい決まっています。図の3つです。

いちばん大きいのは1番です。JS では、プロジェクトごとにライブラリが分かれているのが当たり前なので、「別のプロジェクトで入れたライブラリの版がぶつかる」ことはまずありません。Python では、何も考えずに pip install すると、パソコンの中の同じ Python を使うすべてのプロジェクトが1つの site-packages を共有します。そこで Python では「プロジェクトごとの箱」を自分で作ります。それが仮想環境（venv）で、中身は拍子抜けするほど単純なフォルダです（第12章）。

2番は最初こそ戸惑いますが、1日で慣れます。3番は、Web API を作る段になって効いてきます。

逆に言えば、この3つ以外は「JS と同じ考え方で、名前が違うだけ」のことがほとんどです。

この本で育てるもの ①：天気を表示する1ファイルから

この本では、1つの小さなプログラムを章ごとに育てていきます。題材は、天気を取ってきて表示するコマンド tenki（てんき）です。

最初は、main.py という1つのファイルだけです。ターミナルで python3 main.py と打つと、天気が表示されます。

# main.py
city = "東京"
temp = 24
print(f"{city}：晴れ {temp}度")

$ python3 main.py
東京：晴れ 24度

まだ本物の天気は取ってきていません。値はコードに直接書いてあります。第3〜7章では、この1ファイルを舞台に、Python の文法を JS と並べて覚えます。

この段階では、ライブラリも import もほとんど出てきません。まずは「1つのファイルを Python が読んで実行する」ことを、第1章で分解するところから始めます。

この本で育てるもの ②：ファイルに分け、ライブラリを入れる

中盤で、tenki は図のように育ちます。緑の囲みが tenki/ というプロジェクトのフォルダ、右の青い囲みがインターネットです。

図の矢印は2本あります。PyPI から .venv へ向かう矢印は、requests というライブラリが入ってくる道です（pip install・一度だけ）。.venv から天気の API へ向かう矢印は、tenki が動くたびに requests を使って天気を取りに行く道です。

この2本は、どちらもインターネットを通りますが、意味は全く違います。前者は「道具を買ってくる」、後者は「道具を使って仕事をする」です。この区別がつくと、「pip install は通ったのに、実行すると接続エラーになる」といった状況でも、どちらの道で問題が起きているのかを切り分けられます。

この本で育てるもの ③：配れるパッケージと Web API へ

後半では、tenki を他の人に配れる形にし、最後は Web API にします。

ここまで来ると、tenki はもう「自分のパソコンで動く1ファイル」ではありません。GitHub や PyPI から誰でも入れられ、サーバーの上で動いて、図の右端の「使う人」に天気を返します。

最後の FastAPI では、先ほどの「フレームワークがあなたの関数を呼ぶ」が、実際にどういう順番で起きるのかを分解します。ブラウザからのリクエストを受け取るのはサーバーのプログラム（uvicorn）で、それが FastAPI に渡し、FastAPI があなたの関数を呼ぶ、という3段の流れです。

1ファイルから始めて、同じ題材がここまで育つ流れを追えば、どの段階の「困りごと」を、どの仕組みが解決しているのかが、つながって見えるはずです。

この本の地図

この本は19章（第0〜18章）あります。大きく6つのまとまりに分かれます。

特に大事な山場が3つあります。

第2のまとまり（文法）は、JS が書ける人なら速く読めるはずです。一方、第3・第4のまとまりは、急がずに図を1枚ずつ追ってください。どの章も、1つ前の章の終わりに出てくる疑問を、次の章が解くように並べています。

この本の読み方

この本の各章は、図と本文の2つでできています。

3つ目がいちばん大事です。この本に出てくるパスやコマンドの出力は、読み手の環境によって少しずつ違います。たとえば /Users/you/ の you はあなたのユーザー名に、python3.13 の部分はあなたの Python の版になります。本の出力と自分の出力を見比べて「どこが同じで、どこが違うか」を確かめることが、そのまま仕組みの理解になります。

前提は次のとおりです。

コマンドの例で、行の頭の $ は「ここからがあなたの打つコマンド」という印です。$ 自体は打ちません。>>> は Python の対話モード（第1章）の印です。

約束：読み終えたとき、魔法は1つも残らない

この本を読み終えたとき、あなたは図の5つを、自分の言葉で説明できるようになっています。

こう説明できるようになると、エラーの見え方が変わります。ModuleNotFoundError: No module named 'requests' と出たら、「探している場所（sys.path）に requests が無い。つまり、入れた Python と、いま動いている Python が違うのでは？」と、原因の見当が自分でつけられます。

「なんとなく動く」は、動かなくなったときに手も足も出ません。「こういう順番で動く」は、動かなくなったときにどこが崩れたかを順番にたどれます。この本がめざすのは後者です。

途中で分からなくなったら、第18章の全体の地図に戻ってください。困ったときの確かめ方も、そこにまとめてあります。