Python 08：import の正体 ― 名前だけで、なぜどこから入るのか

一言でいうと：決まった順に棚を見て回る係

import の仕組みは、図書館の係にたとえるとわかりやすくなります。

あなたが「tenki という本をください」と頼むと、係は決まった順番の本棚リストを持っていて、1番目の棚、2番目の棚…と順に見て回ります。背表紙に「tenki」とある本を最初に見つけた棚で探すのをやめ、その本を持ってきます。

この「本棚のリスト」が `sys.path` です。中身は、フォルダのパス（文字列）が並んだ、ただの Python のリストです。

ここで大事なのは、名簿に載っていないフォルダは、どんなに近くにあっても見ないということです。JS（Node.js）では、require("lodash") と書くと、書いたファイルのフォルダから親フォルダへ node_modules を順に遡って探します。Python はそういう「近くを探す」ことをしません。探す場所は名簿がすべてです。

この違いを頭に置いておくと、この先の「なぜ見つからない？」がほとんど説明できるようになります。

ファイル1つが、モジュール1つ

まず言葉をそろえます。Python では、import できる単位をモジュールと呼びます。いちばん基本の形は、.py ファイル1つがモジュール1つです。

名前は、ファイル名から .py を取ったものです。だから import には拡張子もパスも書きません。逆に言うと、ファイル名は Python の名前として使える形にする必要があります。tenki-app.py のようにハイフンを入れると、import tenki-app とは書けません（引き算に見えるため）。

import したモジュールは、名前の入った箱のようなものです。ファイルの中で作った変数や関数が、そのまま箱の中身になります。

import tenki
print(tenki.CITY)     # Tokyo
tenki.show(21)        # Tokyo: 21℃

箱には、Python が自動で入れる名前もあります。__name__ はモジュールの名前（ここでは 'tenki'）、__file__ は実際に読んだファイルのパスです。dir(tenki) で中身の名前を全部出すと、実物はこうなります。

['CITY', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__',
 '__name__', '__package__', '__spec__', 'show']

自分で書いた CITY と show のほかに、Python が付けた名前が並んでいます。__file__ は、この章で何度も使う「どこから来たか」の手がかりです。

import tenki の1行で起きる、4つのこと

import tenki の1行で、Python は次の4つを順番に行います。Python の公式ドキュメント（The import system）に書かれている手順を、言葉を簡単にしたものです。

②で名簿の最後まで見ても無ければ、そこで ModuleNotFoundError になります。

いちばん意外なのは③でしょう。import は、ファイルを「読み込む」だけではなく「実行」します。ファイルの中の print は、import したときに本当に動きます。

もう1つ大事なのは①です。一度 import したモジュールは棚に置かれるので、2回目の import はファイルを探しも実行もせず、棚から取り出すだけです。

実は②の前に、「Python 本体に最初から組み込まれた名前かどうか」も確かめています。sys などがそうです。自分のファイルや pip で入れたライブラリには関係しないので、後で別に見ることにして、まずはこの4つを tenki・json・requests で1段ずつ追いかけます。

名簿の実物：print(sys.path)

名簿 sys.path を実際に出してみます。sys は Python の動いている状態を見せてくれる組み込みのモジュールで、sys.path はただのリストです。

# where.py
import sys
for i, p in enumerate(sys.path):
    print(i, p)

tenki-app というフォルダに where.py を置き、仮想環境（第12章）の python で実行すると、こうなります。

$ .venv/bin/python where.py
0 /Users/you/tenki-app
1 /Library/Frameworks/Python.framework/Versions/3.13/lib/python313.zip
2 /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13
3 /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/lib-dynload
4 /Users/you/tenki-app/.venv/lib/python3.13/site-packages

python.org から入れた Python 3.13 の macOS での形です（筆者の環境で実行した結果のパスを、読みやすい macOS の例に置き換えています。並び順とフォルダ名は実物どおりです）。Homebrew や uv で入れた Python なら、1〜3番の前半が別の場所になりますが、並び方は同じです。

公式ドキュメント（The initialization of the sys.path module search path）によると、名簿はこの順で作られます。

舞台：パソコンの中のフォルダの木

名簿の5つのフォルダは、ディスクの上のどこにあるのでしょうか。フォルダの木にすると、図のように2か所に分かれています。

左はあなたのプロジェクトです。/Users/you/tenki-app の中に、自分で書いた main.py と tenki.py、そして仮想環境の .venv があります。pip で入れた requests は、.venv/lib/python3.13/site-packages/ の中に requests/ というフォルダとして置かれています。

右は Python を入れた場所です。python.org のインストーラーは /Library/Frameworks/Python.framework/Versions/3.13/ に入れます。

注目してほしいのは、標準ライブラリも、あなたの tenki.py と同じ「ディスクの上の .py ファイル」だということです。Finder で開けば中身も読めます。特別な魔法の場所ではありません。

python313.zip は、標準ライブラリを1つの zip にまとめて配る作り方のために名簿へ入っている場所です。Python は zip の中からも import できるのですが、ふつうの環境ではこのファイルは作られていません。無いフォルダやファイルは、探すときに「無かった」として飛ばされるだけで、エラーにはなりません。

木の5か所を、探す順に並べると名簿になる

フォルダの木から、名簿に載っている5か所を取り出して、探す順番に並べ直すと、図の右のようになります。これが sys.path です。

ここから先は、この図を舞台にして import を追いかけます。

名簿のパスは長いので、図では途中を「…」で略しています。実物は前に出した print(sys.path) の出力のとおりです。

main.py の3行を、上から1行ずつ処理します。黒い小包が「いま探している名前」です。小包が棚をのぞき、無ければ名簿の0段目、1段目…と1段ずつ下りていきます。見つかった段は緑の枠と ○、無かった段は灰色と × で示します。

JS から来た人は、ここで「Node の node_modules のように、プロジェクトの中の決まったフォルダを探すのかな」と想像するかもしれません。半分は合っています。4段目の site-packages は、役割としては node_modules に近いものです。違うのは、探す順番が1本の名簿で決まっていて、プロジェクトのフォルダ（0段目）と標準ライブラリが、site-packages より先に来ることです。

import tenki ①：まず棚（sys.modules）を見る

main.py の1行目、import tenki から始めます。

最初に見るのは名簿ではなく、棚です。sys.modules は「モジュールの名前 → モジュール本体」の辞書（JS のオブジェクトや Map にあたるもの。第4章）で、それまでに import したモジュールが全部入っています。

import sys
print(len(sys.modules))       # 35（この環境の場合）
print("tenki" in sys.modules)  # False
print("os" in sys.modules)     # True

プログラムを始めたばかりなのに、棚はもう空ではありません。Python は起動するときに、自分が動くために必要な sys や os などを先に import しているからです。数は環境によって違いますが、数十個あります。

でも、tenki はまだありません。当然です。一度も import していないのですから。

tenki は無かったので、小包は名簿の0段目へ向かいます。

import tenki ②：名簿の0段目で見つかる

名簿の0段目は、起動したスクリプトのあるフォルダ、つまり /Users/you/tenki-app です。python3 main.py と起動したので、main.py のあるフォルダが0段目になっています。

そこに tenki.py があるので、見つかりました。探すのはここで終わりです。

各段で Python が確かめているのは、おおまかに次のものです。

大事なのは、最初に見つかった段で探すのをやめることです。仮に4段目の site-packages にも tenki という名前のライブラリが入っていたとしても、0段目で先に見つかった自分の tenki.py が使われます。この性質は、後で見る「自分のファイル名が本物を隠す事故」の原因にもなります。

JS なら require("./tenki") のように、自分のファイルは ./ で始まる相対パスで書くのが決まりでした。Python では自分のファイルも import tenki と名前だけで書けます。それは、スクリプトのあるフォルダがたまたま名簿の0段目に入っているからです。

import tenki ③：tenki.py を上から実行して、中身を作る

見つけた tenki.py を、Python は上から最後まで実行します。ここが JS の人にとっていちばん意外なところかもしれません。確かめるために、tenki.py の最初と最後に print を仕込んでおきます。

# tenki.py
print("tenki.py を実行中… __name__ =", __name__)

CITY = "Tokyo"

def show(temp):
    print(f"{CITY}: {temp}℃")

print("tenki.py の最後まで来た")

main.py で import tenki するだけで、この2つの print が本当に表示されます。

$ python3 main.py
tenki.py を実行中… __name__ = tenki
tenki.py の最後まで来た

CITY = "Tokyo" も def show も、実行される「文」です。def は「関数を作って show という名前を付ける」という命令なので、実行が通り過ぎたときに初めて関数ができます。こうして最後まで実行し終わったときに残っていた名前（CITY・show）が、モジュール tenki の中身になります。

もう1つ、公式ドキュメントに書かれている細かい順番があります。モジュールは、実行を始める前に棚（sys.modules）に置かれます。図で棚に tenki の札が先に入っているのはそのためです。こうしておくと、tenki.py の中から巡り巡って tenki を import し直しても、無限に繰り返さずに済みます。

なお、実行のついでに __pycache__/tenki.cpython-313.pyc というファイルができます。第1章で見たバイトコードの控えで、次からの読み込みを速くするためのものです。

import tenki ④：main.py に「tenki」という名前を付ける

最後に、import tenki を書いた main.py の中に、`tenki` という名前を作り、できたモジュールを指すようにします。これで tenki.show(21) と書けるようになります。

第4章で「名前は札で、オブジェクトに付ける」と見ました。import も同じです。main.py の名前の表に tenki という札が増え、その札はメモリの中のモジュールに付いています。棚（sys.modules）の "tenki" も、同じモジュールに付いています。

import sys
import tenki
print(sys.modules["tenki"] is tenki)   # True

is は「同じ1つのオブジェクトか」を確かめる比較でした（第3章）。True なので、棚にあるものと、main.py の tenki は、コピーではなく同じ1つです。

ここまでの4段をまとめます。

次は2行目、import json です。今度は0段目では見つかりません。

import json ①：棚には無い

2行目の import json に進みます。json は、JSON 文字列と Python の辞書・リストを相互に変換する標準ライブラリです。JS の JSON.parse / JSON.stringify にあたるものが、Python では import しないと使えません。

標準ライブラリなら最初から読み込まれていそうですが、実際に確かめると違います。

import sys
print("json" in sys.modules)   # False

Python は、起動に必要な最低限のものしか先に import しません。json は、あなたが import したときに初めて探されます。棚にあるのは、今のところ起動時の数十個と、1行目で入った tenki だけです。

JS では JSON は最初からあるグローバルなオブジェクトでした。Python では、標準ライブラリの大部分は「Python と一緒にディスクに置いてあるが、import するまで使えない部品」です。最初から使える print や len などは組み込み関数と呼ばれ、import は要りません。

では、名簿を上から探します。

import json ②：0段目（プロジェクト）には無い

小包は0段目、/Users/you/tenki-app をのぞきます。ここにあるのは main.py と tenki.py と .venv だけです。json.py も json/ フォルダも無いので、×を付けて次の段へ進みます。

ここで一度立ち止まって、もし0段目に json.py があったらを考えてみてください。たとえば練習のつもりで、JSON を試すファイルに json.py という名前を付けていたらどうなるでしょう。

名簿は上から見て、最初に見つけた段で探すのをやめるのでした。0段目の自作 json.py が先に見つかり、2段目にある本物の json には永久に届きません。json.dumps を呼ぶと、「そんなものは無い」というエラーになります。

これは Python を始めたばかりの人がほぼ必ず一度は踏む事故です。実物のエラーは後の「よくある事故」で見ます。対策は簡単で、標準ライブラリや、入れたライブラリと同じ名前のファイルを作らないことです（random.py・email.py・test.py なども要注意です）。

import json ③：1段目（zip）はファイル自体が無い

1段目は /Library/Frameworks/Python.framework/Versions/3.13/lib/python313.zip です。

名前のとおり zip ファイルを指しています。Python は、zip ファイルの中に入った .py を、フォルダの中にあるのと同じように import できます。標準ライブラリを1つの zip にまとめて持ち運べるように、名簿にこの場所が用意されています。

ところが、python.org 版をはじめ、ふつうに入れた Python にはこのファイルがありません。実際、筆者の環境でも ls すると「No such file or directory」でした。名簿に載っているのに、実物が無いのです。

それでも問題はありません。名簿の段は「探しに行く候補」にすぎず、その場所が無ければ何も見つからなかったのと同じ扱いで、黙って次の段へ進みます。

この「名簿には載っているが、実在しなくてもよい」という性質は、自分で PYTHONPATH を設定したときにも同じです。打ち間違えたフォルダを入れても、エラーは出ず、ただ見つからないだけです。「なぜか import できない」ときに気づきにくい原因の1つなので覚えておきましょう。

import json ④：2段目（標準ライブラリ）に json/ がある

2段目は /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13、標準ライブラリの本体です。ここに json/ というフォルダがあり、見つかりました。

json は1つのファイルではなくフォルダです。中を ls すると、実物はこうなっています。

$ ls /Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/json/
__init__.py  __pycache__  decoder.py  encoder.py  scanner.py  tool.py

このように、__init__.py を持ったフォルダをパッケージと呼びます（第9章でくわしく扱います）。フォルダを import すると、中の __init__.py が上から実行され、それがモジュール json の中身になります。json.dumps や json.loads は、この __init__.py の中で定義されています。

>>> import json
>>> json.__file__
'/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/json/__init__.py'

見つかったので、3段目・4段目は見ません。json が棚に入り、main.py に json という名前が付きます。

エディタで json/__init__.py を開いてみてください。先頭には説明の文章があり、その後に from .decoder import JSONDecoder のような、見慣れた Python のコードが続きます。標準ライブラリは、誰かが書いた普通の Python ファイルです。あなたの tenki.py と作りは変わりません。

import requests ①：棚には無い

3行目、import requests です。requests は、インターネットの Web API に HTTP でリクエストを送るためのライブラリで、tenki が天気を取ってくるのに使います（JS の fetch や axios にあたります）。

requests は Python に付いてきません。世界中の誰でもパッケージを置ける PyPI（パイピーアイ、pypi.org）に公開されていて、pip install requests と打つと、ダウンロードされてディスクに置かれます（第11章）。置かれる先が、仮想環境 .venv の中の site-packages です（第12章）。

つまり、import requests の時点でネットにつながる必要はありません。ダウンロードは pip install のときに一度だけ済んでいて、import はディスクの上を探すだけです。

棚には、tenki と json はありますが、requests はまだありません。小包は、名簿の0段目から探し始めます。

import requests ②：0〜2段目には無い

0段目のプロジェクトのフォルダにも、1段目の（存在しない）zip にも、2段目の標準ライブラリにも、requests はありません。3つの段に×が付きました。

2段目の標準ライブラリには、数百のモジュールが入っています（一覧は sys.stdlib_module_names で見られます）。インターネットにアクセスするための urllib もその1つで、実は requests が無くても HTTP のリクエストは送れます。

多くの人が requests を入れて使うのは、書きやすいからです。「標準ライブラリで足りるか」「入れる価値があるか」は、ライブラリを選ぶときにいつも考えることです（第10章）。

さて、残りは3段目と4段目です。

import requests ③：3段目（C 拡張の置き場）にも無い

3段目は …/lib/python3.13/lib-dynload です。ここには、標準ライブラリのうち C 言語で書いてコンパイルした部品が、.so という拡張子のファイルとして置かれています（macOS なら _json.cpython-313-darwin.so のような名前です）。

C で書いた部品を拡張モジュールと呼びます。速さが必要な部分を C で書き、Python からは .py のモジュールとまったく同じように import できます。json の中身も、速くしたい部分はこうした C の部品を使っています。

pip で入れるライブラリにも、C やその他の言語で書かれた拡張モジュールを含むものがあります（numpy など）。そういうライブラリは、OS や CPU ごとに別のファイルが配られます。第11章の wheel の話でまた出てきます。

requests はここにもありません。残るは最後の段だけです。

import requests ④：最後の site-packages で見つかる

4段目、/Users/you/tenki-app/.venv/lib/python3.13/site-packages に、requests/ というフォルダがありました。pip install が置いていったものです。

$ ls .venv/lib/python3.13/site-packages/
certifi/   certifi-2026.7.22.dist-info/   charset_normalizer/ …
idna/      idna-3.20.dist-info/           pip/  pip-25.3.dist-info/
requests/  requests-2.34.2.dist-info/     urllib3/  urllib3-2.8.0.dist-info/

requests も json と同じく、__init__.py を持つフォルダ（パッケージ）です。見つかると、requests/__init__.py が上から実行されます。その中にも import urllib3 などが書かれていて、それぞれが同じ4つの手順で探され、棚に入っていきます。requests の横に urllib3 や idna が並んでいるのは、requests が使う部品として pip が一緒に入れたからです。筆者の環境では、import requests の1行で棚が 59 個から 304 個に増えました。

「pip install した」とは、「名簿の最後の段のフォルダに、ライブラリのフォルダを置いた」ということです。だから import で見つかります。逆に、名簿の最後まで探して無ければ、

ModuleNotFoundError: No module named 'requests'

になります。これが「入れたはずなのに無いと言われる」エラーの正体で、多くは「別の python の site-packages に入れた」ことが原因です（第12章）。

どこから来たかは、__file__ を見ればわかる

ここまでの結果を、実物で確かめます。対話モード（第1章の REPL）で3つを import し、__file__ を出します。

$ .venv/bin/python
>>> import tenki, json, requests
>>> tenki.__file__
'/Users/you/tenki-app/tenki.py'
>>> json.__file__
'/Library/Frameworks/Python.framework/Versions/3.13/lib/python3.13/json/__init__.py'
>>> requests
<module 'requests' from '/Users/you/tenki-app/.venv/lib/python3.13/site-packages/requests/__init__.py'>

モジュールをそのまま表示しても、from '…' の後ろにパスが出ます。

「思っていたのと違うものが動いている」と感じたら、まず __file__ を見てください。自作の json.py に隠されていないか、別の仮想環境のライブラリを使っていないか、パスを見れば一発でわかります。

見つかる場所を、実行せずに調べる方法もあります。importlib.util.find_spec("requests").origin は、import するとしたらどのファイルになるかを返します。ファイルを実行しないので、上から実行されては困るモジュールを調べるときに便利です。

sys にはファイルが無い：Python 本体に組み込まれたもの

sys.__file__ を見ようとすると、エラーになります。

>>> import sys
>>> sys
<module 'sys' (built-in)>
>>> sys.__file__
AttributeError: module 'sys' has no attribute '__file__'

(built-in) は組み込みという意味です。sys は、.py ファイルとしてディスクに置かれているのではなく、Python の実行ファイル（bin/python3.13）の中に最初から入っています。Python が動くために欠かせないものなので、別のファイルにしていないのです。

実は、import でモジュールを探す係は3人いて、この順に聞いて回ります（公式ドキュメントでは sys.meta_path の3つの finder）。

「import tenki の4つのこと」で、②の前に組み込みを確かめると書いたのはこのことです。どれが組み込みかは Python の作り方によって少し違い、sys.builtin_module_names で一覧を見られます。

あなたが書いたファイルや pip で入れたライブラリは、必ず3番目の名簿で見つかります。ふだんは「名簿を上から」だけを覚えておけば困りません。

2回 import しても、実行は1回だけ

import tenki を2回書いたら、tenki.py は2回実行されるでしょうか。確かめます。

# main.py
import sys
import tenki
import tenki      # 2回目
tenki.show(21)
print(sys.modules["tenki"] is tenki)

$ python3 main.py
tenki.py を実行中… __name__ = tenki
tenki.py の最後まで来た
Tokyo: 21℃
True

print は1回ずつしか出ていません。2回目の import は、①で棚に tenki があるのを見つけ、②③を飛ばして④の名前付けだけをしたからです。

これは、別のファイルから import した場合も同じです。main.py と weather.py の両方が import tenki と書いても、tenki.py の実行は最初の1回だけで、両方とも棚にある同じ1つのモジュールを受け取ります。そのため、片方で tenki.CITY = "Osaka" と書き換えると、もう片方からもそう見えます。

最後の行は、対話モードや Jupyter で「ファイルを直したのに変わらない」ときの原因です。importlib.reload(tenki) という手もありますが、いちばん確実なのは Python を起動し直すことです。

JS の Node でも、require は2回目からキャッシュ（require.cache）を返し、ESM も1回しか評価しません。「1回だけ実行して使い回す」という考え方は同じです。

from … import と as：違うのは「付ける名前」だけ

import にはいくつかの書き方があります。表のように、違うのは④で main.py に付ける名前だけで、①〜③（棚を見る・名簿を探す・上から実行）はまったく同じです。

実際に from tenki import show を試しても、tenki.py の print は出ます。

$ python3 -c "from tenki import show; show(18)"
tenki.py を実行中… __name__ = tenki
Tokyo: 18℃

つまり、「必要な関数だけを読むから速くなる」ということはありません。ファイルは必ず最後まで実行され、棚には tenki 全体が入ります。main.py に付く名前が show だけになる、というだけの違いです。

JS の書き方と並べるとこうなります。

from tenki import *（中の名前をほぼ全部持ってくる）は、どの名前がどこから来たか追えなくなるので、ふつうは使いません。as は、import numpy as np のように長い名前を短くする慣習でよく見かけます。

if __name__ == "__main__": の意味

Python のコードでよく見かける、あの1行の意味もここでわかります。

モジュールには __name__ という名前が自動で入るのでした。その値は、どうやって実行されたかで変わります。

実際に試した結果です。

$ python3 tenki.py
tenki.py を実行中… __name__ = __main__
Tokyo: 21℃
$ python3 -c "import tenki"
tenki.py を実行中… __name__ = tenki

import はファイルを上から全部実行するのでした。だから、tenki.py の一番下に動作確認のための show(21) を裸で書いておくと、import されるたびにそれも動いてしまいます。そこで、

if __name__ == "__main__":
    show(21)

と書いておくと、直接実行したときだけ動き、部品として import されたときは動かないファイルになります。モジュールとしても、スクリプトとしても使える書き方です。

JS（Node の CommonJS）にも if (require.main === module) という似た書き方がありますが、あまり使われません。Python ではとてもよく使われるので、見かけたら「直接実行したときの入口だな」と読んでください。

JS（Node）と比べる：探し方・回数・場所

ここまでの内容を、Node.js の CommonJS（require）と ESM（import）に並べます。

Node の仕組みを一言でおさらいします。require("./tenki") のように ./ や ../ で始まるものは、書いたファイルのあるフォルダを基準にした相対パスとして探します。require("lodash") のように名前だけのものは、書いたファイルのフォルダの node_modules、無ければ親フォルダの node_modules…と上の階へ遡って探します。ESM の import も、名前だけのときは同じ探し方です。

いちばん大きな違いは「探す基準」です。Node は書いたファイルの場所から探すので、どのファイルから require したかで結果が変わります。Python は、名簿が1本しかないので、どのファイルに import を書いても同じ場所を探します。

もう1つは「いつ実行されるか」です。Python の import は普通の文なので、関数の中や if の中にも書けて、その行を通ったときに実行されます。ESM の import がファイルの先頭で静的にまとめて処理されるのとは違います。

Node は親フォルダへ遡り、Python は名簿を上から

探し方の違いを、図で並べます。

左は Node です。/Users/you/app/src/index.js で require("lodash") と書くと、Node は require.resolve.paths("lodash") で見られる順に探します。実物の形はこうです。

[
  '/Users/you/app/src/node_modules',
  '/Users/you/app/node_modules',
  '/Users/you/node_modules',
  '/Users/node_modules',
  '/node_modules',
  '/Users/you/.node_modules',
  '/Users/you/.node_libraries',
  '/usr/local/lib/node'
]

書いたファイルのフォルダから、ルート（/）まで1階ずつ上がっていき、最後にいくつかの共通の場所を見ます。書いたファイルが変われば、名簿も変わります。

右は Python です。名簿は起動したときに1本だけ作られ、どのファイルから import しても同じ名簿を使います。

この違いから、Python では「どこから起動したか」が効いてきます。python3 scripts/run.py のように別のフォルダのスクリプトを起動すると、0段目は scripts/ になり、プロジェクトの一番上にある tenki.py は見つからなくなります。これは第9章で実物を見ます。

よくある事故：自分のファイル名が、本物を隠す

前に予告した事故の実物です。練習用のフォルダ /Users/you/practice に、JSON を試すファイルを json.py という名前で作りました。

# json.py
import json
print(json.dumps({"a": 1}))

実行すると、こうなります。

$ python3 json.py
Traceback (most recent call last):
  File "/Users/you/practice/json.py", line 1, in <module>
    import json
  File "/Users/you/practice/json.py", line 2, in <module>
    print(json.dumps({"a": 1}))
AttributeError: module 'json' has no attribute 'dumps' (consider renaming
'/Users/you/practice/json.py' since it has the same name as the standard library
module named 'json' and prevents importing that standard library module)

import json は名簿の0段目（practice フォルダ）で、自分自身の json.py を見つけてしまいました。json.py は __main__ として動いている途中で、もう一度「json」という名前のモジュールとして上から実行されます。Traceback に json.py が2回出てくるのはそのためです。その json.py には dumps が無いので、「json に dumps は無い」と言われます。

Python 3.13 からは、括弧の中のように「標準ライブラリと同じ名前だから、名前を変えて」と教えてくれるようになりました。ただし、requests.py のように pip で入れたライブラリと同じ名前の場合は、筆者が試した範囲では、そのファイル自身を実行したときにしかヒントが出ず、main.py から import した場合はただの AttributeError: module 'requests' has no attribute 'get' でした。

直すには、ファイルの名前を変え、同じフォルダにできた __pycache__ も消しておくと確実です。

ModuleNotFoundError：名簿の最後まで無かった

import でいちばんよく見るエラーがこれです。

Traceback (most recent call last):
  File "/Users/you/tenki-app/main.py", line 3, in <module>
    import requests
ModuleNotFoundError: No module named 'requests'

意味はこの章の言葉で言えば、「名簿（sys.path）のどの段にも、requests が無かった」です。原因は、名簿が思っていたのと違うか、置いた場所が違うか、名前が違うかのどれかです。

どの原因でも、確かめる方法は同じです。エラーになった python と同じ python で `print(sys.path)` を出し、目当てのフォルダが名簿にあるかを見ます。名簿にフォルダがあり、その中に目当てのファイルがあれば、必ず見つかります。無ければ、見つからないのが正しい動きです。

import のエラーは、慣れないうちは「Python の機嫌」のように見えます。でも、仕組みは「名簿を上から探す」だけなので、名簿と置き場所を見比べれば、必ず原因にたどり着けます。

tenki を2つのファイルに分ける

この章の内容を使って、tenki を2つのファイルに分けます。

# tenki.py
CITY = "Tokyo"

def fetch(city):
    # 第11章で requests に置き換える
    return {"city": city, "temp": 21}

def show(data):
    print(f"{data['city']}: {data['temp']}℃")

# main.py
import tenki

if __name__ == "__main__":
    data = tenki.fetch(tenki.CITY)
    tenki.show(data)

$ cd ~/tenki-app
$ python3 main.py
Tokyo: 21℃

python3 main.py と起動すると、main.py のあるフォルダ（tenki-app）が名簿の0段目になり、同じフォルダの tenki.py が見つかります。tenki.py には print も入口も置かず、import されても何も起きない部品にしておくのがコツです。そうしておけば、後でテスト（第15章）や Web API（第17章）から tenki を import したときにも、余計なことが起きません。

ファイルが増えてきたら、次は tenki/ というフォルダにまとめたくなります。それが次の章のパッケージです。