Python 3.13の新機能と3.12との違い｜GIL無効化の実測・削除モジュール・サポート期限

Python 3.13は2024年10月7日に公開された系列で、2026年9月時点の最新パッチは3.13.15（2026年8月5日公開）です。目玉はGILを外して動くフリースレッド版と実験的なJITコンパイラですが、どちらも既定では無効で、普段の利用で体感が変わるのは新しい対話型シェルとエラーメッセージです。いっぽう、cgiやtelnetlibなど19の標準モジュールが削除されたため、3.12から上げると古いコードは起動時に止まります。

この記事では3.12との違いを一覧にしたうえで、フリースレッド版を手元で計測した数値、上げると動かなくなるコード、サポート期限から見た3.14との選び方を順に説明します。Pythonの最新系列は3.14で、その新機能はPython 3.14の新機能（JITコンパイラ・フリースレッド版・t-string）で扱っています。

まとめ：Python 3.13で押さえる要点

• 3.13.0は2024年10月7日公開。最新は3.13.15で、バイナリインストーラ付きのバグ修正は2026年10月6日予定の3.13.16が最後です。以降は2029年10月までソース配布のセキュリティ修正のみになります。
• フリースレッド版（python3.13t）は実験扱いです。手元の計測では4スレッドのCPU処理が1.14秒から0.30秒に縮みましたが、GIL非対応のC拡張を1つ読み込むだけでGILが戻ります。
• JITコンパイラは --enable-experimental-jit 付きでビルドしたときだけ入ります。3.13の公式インストーラには含まれません。
• cgi・telnetlib・crypt・imghdr・pipesなど19モジュールと、lib2to3・tkinter.tixが削除されました。classmethodでpropertyを包む書き方も動かなくなっています。
• 2026年に新しく始めるなら3.14を選びます。Debian 13の標準が3.13であるなど、配布元に合わせる必要があるときは3.13のままで問題ありません。

Python 3.13のリリース時期とサポート期限

Pythonは毎年10月に新しい系列を出し、3.13以降の各系列は約2年のバグ修正期間と約3年のセキュリティ修正期間を合わせて約5年間サポートされます（PEP 602）。3.12のバグ修正期間は約1年半でした。3.13のスケジュールはPEP 719に定められており、系列ごとの状態は次のとおりです。

PEP 719（Python 3.13 Release Schedule）には、3.13.16（2026年10月6日予定）が「バイナリインストーラ付きの最後の定期バグ修正版」と明記されています。その後もセキュリティ修正は出ますが、ソースだけの配布です。python.orgのWindows・macOS向けインストーラで3.13を入れている場合、10月以降はパッチを当てるたびに自分でビルドするか、OSのパッケージやuvなど再配布元のビルドに頼ることになります。

手元の版はターミナルで確認できます。フリースレッド版の場合、-VV の出力に「experimental free-threading build」と表示されます。

$ python3.13 -VV
Python 3.13.14 (main, Jul 18 2026, 16:55:19) [Clang 22.1.3 ]
$ python3.13t -VV
Python 3.13.14 experimental free-threading build (main, Jul 18 2026, 17:06:26) [Clang 22.1.3 ]

複数の版を並べて入れる方法はpyenvでPythonのバージョンを切り替える手順で解説しています。

3.12から3.13で変わった点の一覧

公式のWhat’s New in Python 3.13から、利用者側に影響の大きいものを抜き出しました。上ほど影響が大きい変更です。

フリースレッド版（GIL無効化）の使い方と実測

GIL（グローバルインタプリタロック）は、1つのプロセス内でPythonのバイトコードを同時に実行できるスレッドを1本に絞る仕組みです。3.13ではPEP 703にもとづき、GILを外したビルドが実験的に用意されました。通常の python3.13 とは別の実行ファイル（python3.13t）として提供され、既定のPythonの挙動は変わりません。

python3.13tの入手と確認方法

python.orgのWindows・macOS用インストーラでは、フリースレッド版のバイナリをオプションとして追加できます。ソースからビルドする場合は --disable-gil を付けます。uvを使っているなら次の1行で入ります。

$ uv python install 3.13t
 + cpython-3.13.14+freethreaded-macos-x86_64-none (python3.13t)

実際にGILが外れているかは sys._is_gil_enabled() で確かめます。フリースレッド版でも、環境変数 PYTHON_GIL=1 かオプション -X gil=1 を付ければGILを有効にして動かせます。C拡張を含むパッケージをフリースレッド版に入れるには、pip 24.1以降が必要です。

スレッド並列の実測値

各スレッドで300万回の純Pythonループを実行し、1本・4本・8本について3回の最短時間を比べました。総処理量はスレッド数に比例して増え、一定量の仕事を分割する比較ではありません。計測環境はIntel Core i9-9880H（8コア16スレッド）のmacOSで、各版はuvが配布するビルドを使っています。

import sys, threading, time

def work(n):
    s = 0
    for i in range(n):
        s += i * i % 7
    return s

def run(k, n=3_000_000):
    ts = [threading.Thread(target=work, args=(n,)) for _ in range(k)]
    t = time.perf_counter()
    for x in ts: x.start()
    for x in ts: x.join()
    return time.perf_counter() - t

for k in (1, 4, 8):
    print(k, round(min(run(k) for _ in range(3)), 2), getattr(sys, "_is_gil_enabled", lambda: True)())

GILありの版は、スレッドを増やしても処理が1本ずつしか進まないため、時間がスレッド数に比例して延びます。フリースレッド版は8スレッドでもほぼ1スレッド分の時間で終わりました。代わりに1スレッドの時間は3.13tが0.30秒、通常の3.13が0.27秒で、約1割遅くなっています。

この約1割は単純なループ1種類での数字です。公式のフリースレッド解説（Python 3.13ドキュメント）は、3.13tの単一スレッドのオーバーヘッドをベンチマーク集pyperformanceで「約40%」としています。最大の要因は、処理を型ごとに特化させる高速化（PEP 659）がフリースレッド版では無効になっていることです。3.14ではこれが再び有効になり、3.14のWhat’s Newには低下幅が「おおむね5〜10%」と記載されています。今回の計測でも、3.14tの1スレッドは通常版との差が0.01秒でした。自分の処理で同じ比較をしてから判断してください。

C拡張の読み込みでGILが戻る挙動

フリースレッド版の落とし穴は、GILなしで動けると宣言していないC拡張を1つ読み込んだ時点で、プロセス全体のGILが自動で有効に戻ることです。複数フェーズ初期化の拡張は Py_mod_gil スロットで、単一フェーズ初期化の拡張は PyUnstable_Module_SetGIL() でGILなしの実行への対応を宣言します。宣言を持たない最小のC拡張を自作して確かめました。次の legacy.c と setup.py を同じディレクトリに保存し、3.13tの仮想環境でビルドします。

/* legacy.c：Py_mod_gil を宣言しない拡張 */
#include <Python.h>
static PyModuleDef_Slot slots[] = {{0, NULL}};
static struct PyModuleDef m = {PyModuleDef_HEAD_INIT, "legacy", NULL, 0, NULL, slots};
PyMODINIT_FUNC PyInit_legacy(void) { return PyModuleDef_Init(&m); }

# setup.py
from setuptools import setup, Extension
setup(name="legacy", ext_modules=[Extension("legacy", ["legacy.c"])])

$ python3.13t -m venv vt
$ vt/bin/pip install setuptools
$ vt/bin/python setup.py build_ext --inplace

できた拡張を読み込むと、次のようになりました。

$ vt/bin/python -c "import sys; print('before', sys._is_gil_enabled()); import legacy; print('after', sys._is_gil_enabled())"
<frozen importlib._bootstrap>:488: RuntimeWarning: The global interpreter lock (GIL) has been enabled to load module 'legacy', which has not declared that it can run safely without the GIL. To override this behavior and keep the GIL disabled (at your own risk), run with PYTHON_GIL=0 or -Xgil=0.
before False
after True

警告は1行出るだけで処理は続くため、ログを見なければ並列化が効いていないことに気づけません。PYTHON_GIL=0 で強制的に外すこともできますが、その拡張がスレッド安全である保証はありません。導入前に、依存するC拡張すべてにフリースレッド版向けのwheel（ファイル名に cp313t を含むもの）があるかを確認し、起動後に sys._is_gil_enabled() が False のままかをログに出しておくと安全です。

実験的JITコンパイラの有効化条件

PEP 744で追加されたJITは、実行中の命令列を中間表現（Tier 2 IR）に変換し、機械語に置き換える仕組みです。3.13では --enable-experimental-jit を付けてCPythonをビルドしたときだけ組み込まれ、公式インストーラには入っていません。そうしたビルドでは、環境変数 PYTHON_JIT=0 または PYTHON_JIT=1 で実行時に無効・有効を切り替えられます。

What’s Newは効果を「控えめ（modest）」と書いています。3.14では公式のmacOS・Windowsバイナリに実験的JITが同梱され、PYTHON_JIT=1 だけで試せるようになりましたが、効果は「10%遅い〜20%速い」幅と説明されており、本番利用は推奨されていません。JITとインタプリタの違いはJITコンパイラとは？仕組み・種類とAOT・インタプリタの違いを参照してください。

新しい対話型シェルとエラーメッセージの改善

対話型シェル（REPL）の新機能

ターミナルで python3.13 を起動すると、PyPyのコードをもとにした新しいシェルが立ち上がります。追加された主な機能は次のとおりです。

• 複数行のブロックを履歴から呼び戻して、そのまま編集できる
• exit・quit・help を括弧なしで実行できる
• プロンプトとトレースバックが色付きで表示される
• F1でヘルプ閲覧、F2で出力を除いた入力履歴、F3で貼り付けモード

以前のシェルに戻すには環境変数 PYTHON_BASIC_REPL を設定します。色が不要な場合は PYTHON_COLORS=0 か NO_COLOR で消せます。

エラーメッセージの改善

3.12と3.13で同じミスを実行すると、3.13のほうが原因まで示してくれます。1つめは、作業フォルダに random.py を置いてしまい、標準モジュールの random が読めなくなった場合です。

# Python 3.12
AttributeError: partially initialized module 'random' has no attribute 'randint' (most likely due to a circular import)

# Python 3.13
AttributeError: module 'random' has no attribute 'randint' (consider renaming '/private/tmp/py313/shadow/random.py' since it has the same name as the standard library module named 'random' and prevents importing that standard library module)

2つめは、キーワード引数の綴り間違いです。3.13は正しい引数名の候補を出します。

>>> sorted([3, 1], reverso=True)
# 3.12: TypeError: 'reverso' is an invalid keyword argument for sort()
# 3.13: TypeError: sort() got an unexpected keyword argument 'reverso'. Did you mean 'reverse'?

言語仕様・型ヒント・標準ライブラリの変更

locals()とf_localsの意味論（PEP 667）

関数内での locals() は、3.13から呼び出した時点のスナップショットを返すと定義されました。書き換えてもローカル変数には反映されません。いっぽう、フレームの f_locals は FrameLocalsProxy という書き込みが反映される窓口に変わり、デバッガがローカル変数を確実に書き換えられるようになりました。

import sys

def h():
    x = 1
    sys._getframe().f_locals["x"] = 99
    print(x)

h()   # 3.12は1、3.13は99

普通のアプリケーションコードで f_locals を書き換えることはまれですが、デバッガやプロファイラ、テスト用のモックを自作している場合は挙動が変わります。

型ヒントの追加（PEP 696・702・705）

型ヒントの追加から、ここでは3つを紹介します。TypeVar に既定値を指定できるようになり（PEP 696）、非推奨を示す warnings.deprecated デコレータが入り（PEP 702）、TypedDictの項目を読み取り専用にする typing.ReadOnly が加わりました（PEP 705）。@deprecated を付けた関数を呼ぶと、実行時に DeprecationWarning が出ます。

import warnings
from typing import TypeVar, TypedDict, ReadOnly
from warnings import deprecated

T = TypeVar("T", default=int)
print(T.__default__)            # <class 'int'>

class Config(TypedDict):
    name: ReadOnly[str]         # 型チェッカーが再代入を検出する

@deprecated("use load_v2")
def load(): ...

with warnings.catch_warnings(record=True) as w:
    warnings.simplefilter("always")
    load()
    print(w[0].category.__name__, w[0].message)   # DeprecationWarning use load_v2

標準ライブラリで増えた関数とモジュール

• copy.replace()：dataclassや名前付きタプルなどから、一部の値だけを差し替えた新しいオブジェクトを作る。3.12では AttributeError になります。
• dbm.sqlite3：SQLiteを使う dbm のバックエンドで、新規作成時の既定になりました。手元でも dbm.whichdb() が dbm.sqlite3 を返しました。
• os.process_cpu_count()：プロセスが実際に使えるCPU数を返します。呼び出し元スレッドのCPUアフィニティによっては os.cpu_count() より小さい値を返します。コンテナのCPU時間割り当て上限を、そのままCPU数として返す関数ではありません。
• base64.z85encode()：Z85形式のエンコードとデコードが追加されました。
• docstringの各行に共通する行頭の空白がコンパイル時に取り除かれ、.pyc が小さくなります。docstringの文字列を厳密に比較するテストは結果が変わります。

3.13へ上げると動かなくなるコード

削除された標準モジュールと代替手段

3.11で非推奨になっていたPEP 594の19モジュール（aifc・audioop・cgi・cgitb・chunk・crypt・imghdr・mailcap・msilib・nis・nntplib・ossaudiodev・pipes・sndhdr・spwd・sunau・telnetlib・uu・xdrlib）が削除され、あわせて2to3ツールとlib2to3、tkinter.tixも消えました。3.13でこれらをimportすると ModuleNotFoundError になります。What’s Newが示す代替のうち、利用の多いものを並べます。

すぐに書き換えられない場合は、PyPIの再配布パッケージ（standard-telnetlib・standard-imghdr など）で当面しのげます。3.13.14に入れて試すと、importはできるものの「標準ではなく別途インストールした版を使っている」という DeprecationWarning が出ました。あくまで移行までのつなぎです。

classmethodとpropertyの重ね掛けの廃止

@classmethod と @property を重ねてクラス属性のように読む書き方は、3.13で使えなくなりました。例外にはならず、値の代わりにメソッドオブジェクトが返るため、壊れた箇所から離れた場所でエラーになります。症状と書き換え方はPythonの@classmethodとは｜clsの役割とstaticmethodとの違いで実行例付きで説明しています。

3.12から移行する手順

1. 3.12のまま python -W error::DeprecationWarning -m pytest を実行します。削除予定モジュールは3.12でimport時に「slated for removal in Python 3.13」という警告を出すため、例外に変えれば洗い出せます。ただしclassmethodの件は警告が出ないので、grepで @classmethod と @property の重ね掛けを探します。
2. 依存パッケージのPyPIページで cp313 専用のwheelだけでなく、互換性のある abi3 や py3-none-any のwheelも確認します。対応wheelがない場合はソースからビルドすることがありますが、純Pythonのパッケージでは通常Cコンパイラは不要です。
3. uv python install 3.13 や pyenv install 3.13.15 で並行して入れ、仮想環境を作り直してテストを通します。

2026年のPython 3.13・3.14の選定基準

新しく始めるプロジェクトなら3.14を選びます。3.13のバイナリ付きバグ修正は2026年10月で終わるのに対し、3.14は2027年10月までバグ修正が続き、サポート終了も1年遅い2030年10月です。フリースレッド版を試すのが目的なら、なおさら3.14です。3.14ではPEP 779により「実験的」から「公式サポート（ただし任意）」の段階に上がり、単一スレッドの性能低下も縮んでいます。Ubuntu 26.04 LTSの標準Pythonも3.14です（Ubuntu 26.04 LTS 開発者向け詳細）。

3.13のままでよいのは次のような場合です。

• OS付属のPythonを使う：Debian 13（trixie）の標準Pythonは3.13です。OSのセキュリティ更新が続く間は、配布元がパッチを当てた3.13を使い続けられます。
• 依存ライブラリが3.14向けwheelをまだ出していない：ビルド環境を用意するより、対応を待つほうが安く済みます。
• 3.13で動いている本番環境：2029年10月までセキュリティ修正は出るため、急いで上げる理由はありません。ただし2026年10月以降は、python.orgのインストーラでパッチを当てる運用は続けられません。

3.12以前から移行する場合も、依存ライブラリとアプリケーションが3.14に対応していれば、3.14を選びます。3.14固有のAPI削除や挙動変更への対応が難しい場合は、3.13を経由する判断もあります。3.13で削除されたモジュールへの対応はどちらを選んでも必要です。3.14固有の変更にも対応できるなら、一度で3.14まで上げたほうが次の移行までの期間を1年長く取れます。スレッドとは別の並行処理モデルとの違いはグリーンスレッドとは？OSスレッドとの違いとN:1モデルの制約を実測で解説にまとめています。

よくある質問

Python 3.13はいつまで使えますか？

セキュリティ修正は2029年10月まで提供されます。ただしWindows・macOS向けのインストーラが付くバグ修正版は、2026年10月6日予定の3.13.16が最後です。

Python 3.13と3.14はどちらをインストールすればよいですか？

新規なら3.14です。サポート期間が1年長く、フリースレッド版も公式サポートの段階にあります。OS付属の3.13を使う場合や、依存ライブラリが3.14に未対応の場合は3.13を選びます。

フリースレッド版の3.13tは本番環境で使えますか？

3.13では実験扱いなので、本番には勧められません。GIL非対応のC拡張を読み込むとGILが自動で戻るうえ、単一スレッドの処理は公式の計測で約40%遅くなります。試すなら公式サポートに上がった3.14tを使ってください。

Python 3.13のJITはどうやって有効にしますか？

CPythonを --enable-experimental-jit 付きでソースからビルドする必要があります。python.orgの3.13インストーラには含まれていません。

3.13で削除されたcgiやtelnetlibを使い続ける方法はありますか？

PyPIの standard-cgi や standard-telnetlib を入れればimportできます。ただし警告が出るつなぎの手段なので、公式が示す代替ライブラリへの移行を進めてください。

関連記事

• Python 3.14の新機能まとめ｜JITコンパイラ・フリースレッド版(GIL撤廃)・t-stringを最新版で解説
• pyenvでPythonのバージョンを切り替える手順｜shimの仕組みとビルド失敗の対処
• Pythonの@classmethodとは｜clsの役割とstaticmethodとの違い
• JITコンパイラとは？仕組み・種類とAOT・インタプリタの違いをわかりやすく解説
• Ubuntu 26.04 LTS 開発者向け詳細｜言語バージョン・x86-64-v3・フレーバー・サポート期間