Python 3.13の新機能と3.12との違い｜3.13.17の変更点・サポート期限・GIL無効化の実測

Python 3.13は2024年10月7日に公開された系列です。2026年9月30日公開の3.13.16で通常のバグ修正が終わり、10月からはセキュリティ修正だけの段階に入りました。2026年10月25日時点の最新パッチは、証明書の差し替えのために臨時で出た3.13.17（10月21日公開）です。サポートは2029年10月まで続きます。

新機能の目玉はGILを外して動くフリースレッド版と実験的なJITコンパイラですが、どちらも既定では無効です。普段の利用で変化を感じるのは、新しい対話型シェルとエラーメッセージでしょう。いっぽう、cgiやtelnetlibなど19の標準モジュールが削除されたため、これらを使うコードは、代替パッケージなどで対応していなければ該当モジュールのimport時にエラーになります。Pythonの最新系列は2026年10月9日に出た3.15で、新機能はPython 3.15の新機能｜遅延インポートとUTF-8既定化、ひとつ前の3.14はPython 3.14のJITコンパイラとフリースレッド版で扱っています。

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

• 3.13.0は2024年10月7日公開。3.13.16（2026年9月30日）が最後の通常バグ修正版で、以降は2029年10月までセキュリティ修正のみです。
• 3.13.17（2026年10月21日）は、pipに同梱された証明書を更新するための特別版です。インストーラが付くのは例外で、今後のセキュリティ修正はソース配布だけになります。既存の仮想環境のpipは自動では新しくならないので、手で上げます。
• フリースレッド版（python3.13t）は実験扱いです。手元の計測では4スレッドのCPU処理が1.14秒から0.30秒に縮みましたが、GIL非対応のC拡張を1つ読み込むだけでGILが戻ります。
• cgi・telnetlib・crypt・imghdr・pipesなど19モジュールと、lib2to3・tkinter.tixが削除されました。classmethodでpropertyを包む書き方も動かなくなっています。
• 2026年10月に新しく始めるなら3.14を選びます。依存ライブラリがそろっていれば3.15も候補です。OS付属のPythonが3.13の環境や、3.13で動いている本番環境は2029年10月まで使い続けられます。

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

Pythonは毎年10月に新しい系列を出し、3.13以降の各系列は約2年のバグ修正期間と約3年のセキュリティ修正期間を合わせて約5年間サポートされます（PEP 602）。3.12のバグ修正期間は約1年半でした。peps.python.orgが公開している系列ごとの状態のデータと、python.orgのリリース一覧から、2026年10月25日時点の状況をまとめます。

3.13のスケジュールを定めたPEP 719（Python 3.13 Release Schedule）は、3.13.16を「Final regular bugfix release with binary installers」と位置づけ、その後のセキュリティ修正は「Source-only」で2029年10月まで必要に応じて出すとしています。python.orgのWindows・macOS向けインストーラで3.13を入れている場合、今後のパッチは自分でビルドするか、OSのパッケージやuvなど再配布元のビルドに頼ることになります。3.13.17のようにインストーラ付きで出るのは、緊急性が高いときの例外です。

3.13.16と3.13.17で変わった点

3.13.16には脆弱性修正が含まれ、3.13.17では同梱pipの証明書バンドルが更新されています。結論から言うと、3.13.15以前を使っているなら3.13.17まで上げます。2つのリリースの中身は性格がまったく違います。

3.13.16：最後の通常バグ修正版

3.13.16のリリースページによると、3.13.15から約290件のバグ修正・ビルド改善・文書修正が入りました。セキュリティ関連の主な修正は次のとおりです。

• tarfile の展開フィルタの回避（CVE-2026-82049・CVE-2026-19672・CVE-2026-87910）。ハードリンクとシンボリックリンクを組み合わせると、展開先の外にディレクトリを作れたり、ファイルを書き換えられたりしました。
• ssl の修正2件。sni_callback でコンテキストを切り替えたときの解放後使用（CVE-2026-19445）と、SSLContext.wrap_bio() での server_hostname の検証漏れ（CVE-2026-19553）です。
• zipfile でbzip2・LZMA・Zstandardを展開するときのメモリ枯渇（CVE-2026-15310）と、urllib.request.HTTPPasswordMgr がある方式のURL向け認証情報を別の方式へ送ってしまう問題（CVE-2026-15806）。
• Windows・macOS・Android向けに同梱するOpenSSLを3.0.21から3.5.9へ更新。3.5系はOpenSSLの長期サポート版です。同梱のExpatも2.8.5になりました。

macOS 27.0では、IDLEなどtkinterを使うアプリでダイアログを開くと固まる問題が報告されています。3.13.16のリリースページは、Tkを使うアプリに依存しているならmacOS 27.0への更新を見送るよう案内していました。この問題には、次の3.13.17のmacOS版インストーラで対処が入りました。

3.13.17：証明書を差し替える特別セキュリティ版

3.13.17のリリースページは、この版を「special security release」と呼んでいます。中身は、同梱するpipを26.2.2に上げ、pipが持つ証明書バンドル（certifi）を2026.10.19にすることです。eMudhra・emSignの認証局で起きた証明書のセキュリティ事案への対応で、通常はセキュリティ版でpipを上げないものの、3.13がセキュリティ修正のみの段階に入った直後なのでインストーラ付きで出すと説明されています。macOS版のインストーラはTkのプレリリース版でビルドされ、macOS 27.0でtkinterが固まる問題も直っています。

注意点は、Python本体を更新しても、既存の仮想環境にインストール済みのpipは自動更新されないことです。リリースページも、既存の仮想環境ではpipとuvを最新に上げるよう求めています。証明書事案への対応として、同ページにはpip 26.2.2のwheelのURLとSHA-256を固定した更新コマンドも掲載されているため、安全な更新にはその手順を参照してください。手元でソースからビルドした3.13.17（チェックサムはリリースページの値と一致）と、uvが配布する3.13.14で確かめました。

# 3.13.17で新しく作った仮想環境
$ python3.13 -m venv v17
$ v17/bin/python -c "import pip; from pip._vendor import certifi; print(pip.__version__, certifi.__version__)"
26.2.2 2026.10.19

# 3.13.14で作った仮想環境（そのまま）
$ v13/bin/python -c "import pip; from pip._vendor import certifi; print(pip.__version__, certifi.__version__)"
26.1.2 2026.02.25

# 既存の仮想環境でpipを上げる
$ v13/bin/python -m pip install --upgrade pip
$ v13/bin/python -c "import pip; from pip._vendor import certifi; print(pip.__version__, certifi.__version__)"
26.2.2 2026.10.19

仮想環境の中のpipは、作成したときに ensurepip がコピーしたものです。インタプリタを3.13.17に上げても、作り直さない限り中身は古いままです。python -m pip install --upgrade pip を実行すると、3.13.14の仮想環境でもpip 26.2.2・certifi 2026.10.19になりました。仮想環境が多い場合は、作り直すより各環境でこの1行を流すほうが早く済みます。なお、PyPIのcertifi単体は2026年10月25日時点で2026.10.23まで進んでいます。requests などが使うのはこちらのcertifiなので、pip install --upgrade certifi も合わせて実行してください。

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回の最短時間を比べました。総処理量はスレッド数に比例して増え、一定量の仕事を分割する比較ではありません。計測日は2026年9月26日です。計測環境は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では、Unix系は --enable-experimental-jit、Windowsは PCbuild/build.bat --experimental-jit を指定してビルドすると組み込まれ、公式インストーラには入っていません。そうしたビルドでは、環境変数 PYTHON_JIT=0 または PYTHON_JIT=1 で実行時に無効・有効を切り替えられます。

What’s Newは効果を「控えめ（modest）」と書いています。3.14では公式のmacOS・Windowsバイナリに実験的JITが同梱され、PYTHON_JIT=1 だけで試せるようになりました。3.15.0のリリースページは、x86-64のLinuxで標準のインタプリタより幾何平均7〜8%速くなったとしています。JITを試すのが目的なら、3.13で自前ビルドするより3.14以降を使うほうが早道です。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・742）

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

もう1つの typing.TypeIs（PEP 742）は、型を判定する関数の戻り値に付ける注釈です。従来の TypeGuard は判定が真のときしか型を絞り込めませんでしたが、TypeIs は偽のときも残りの型へ絞り込みます。

from typing import TypeIs

def is_str(x: object) -> TypeIs[str]:
    return isinstance(x, str)

def f(v: str | int) -> None:
    if is_str(v):
        print(v.upper())   # v は str
    else:
        print(v + 1)       # v は int（TypeGuardでは str | int のまま）

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

• 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. 3.13を並行して入れ（次の章）、仮想環境を作り直してテストを通します。

業務システムの言語ランタイムを計画的に上げる作業は、依存ライブラリの棚卸しとテストの整備が大半を占めます。社内で手が回らない場合はシステムマイグレーション・リプレイスの支援もご相談いただけます。

Python 3.13を入れる方法と版の確認

手元の版はターミナルで確認できます。フリースレッド版の場合、-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 ]

入れ方は環境で分かれます。3.13.17のリリースページには、Windows向けにフルインストーラ（64ビット版を推奨、32ビット版も提供、ARM64版は実験扱い）と、Python install managerで py install 3.13 と打って入れる方法が並んでいます。macOSは「macOS 10.13 and later」のpkgインストーラです。

• Linux：Debian 13（trixie）の標準Pythonは3.13系なので、apt install python3 で入ります。Ubuntu 26.04 LTSの標準は3.14で、3.13を並べる方法はUbuntu 26.04 LTS 開発者向け詳細にまとめています。
• uv：uv python install 3.13 で入ります。ただし候補に出る版はuv本体の版で決まり、手元のuv 0.11.31（2026年7月のビルド）では3.13.14が上限でした。3.13.16以降を入れるにはuv本体の更新が先です。
• pyenv：pyenv install 3.13.17 でソースからビルドします。3.13.17の定義はpyenv v2.8.13（2026年10月22日）で追加され、v2.8.12には入っていないので、pyenv本体を更新してから実行します。手順はpyenvでPythonのバージョンを切り替える手順で解説しています。

2026年10月時点の3.13・3.14・3.15の選び方

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

3.15は2026年10月9日に出たばかりです。サポート期間は最も長いものの、UTF-8の既定化（PEP 686）でファイルの文字コードの扱いが変わるうえ、C拡張を含む依存ライブラリの3.15向けwheelがそろうまで少し時間がかかります。依存ライブラリが3.15に対応し、cp315 専用wheelだけでなく互換性のある abi3 や py3-none-any のwheel、またはソースからのビルドで動作確認できれば3.15を選べます。対応が確認できない場合は3.14を選びます。

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

• OS付属のPythonを使う：Debian 13の標準Pythonは3.13系です。OSのセキュリティ更新が続く間は、配布元がパッチを当てた3.13を使い続けられます。
• 3.13で動いている本番環境：2029年10月までセキュリティ修正は出るため、急いで上げる理由はありません。ただし今後のパッチはソース配布が原則なので、python.orgのインストーラで更新している環境は、更新の手段を先に決めておきます。

3.12以前から移行する場合、3.13で削除されたモジュールへの対応はどの版を選んでも必要です。3.14固有の変更にも対応できるなら、一度で3.14まで上げたほうが次の移行までの期間を1年長く取れます。スレッドとは別の並行処理モデルとの違いはグリーンスレッドとは？OSスレッドとの違いとN:1モデルの制約を実測で解説にまとめています。

よくある質問

Python 3.13のサポート期限はいつまでですか？

セキュリティ修正は2029年10月まで提供されます。バグ修正は2026年9月30日公開の3.13.16で終わり、10月からはセキュリティ修正のみの段階です。

Python 3.13.17はどんな版ですか？

2026年10月21日に出た特別セキュリティ版です。同梱のpipを26.2.2に、証明書バンドルのcertifiを2026.10.19に上げています。既存の仮想環境は自動では更新されないので、python -m pip install --upgrade pip で上げてください。

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

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

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

3.13では実験扱いなので、本番には勧められません。GIL非対応のC拡張を読み込むとGILが自動で戻ります。単一スレッド実行のオーバーヘッドも、公式文書ではベンチマーク集pyperformanceで約40%です（C拡張やI/Oが中心の処理では影響が小さくなります）。試すなら公式サポートに上がった3.14t以降を使ってください。

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

ソースからJITを組み込んでビルドします。Unix系では --enable-experimental-jit、Windowsでは PCbuild/build.bat --experimental-jit を指定します。python.orgの3.13インストーラには含まれていません。

関連記事

• Python 3.15の新機能｜遅延インポートとUTF-8既定化、3.14から上げる手順
• Python 3.14のJITコンパイラとは？有効化の手順と3.15.0までの実測、フリースレッド版と新機能
• pyenvでPythonのバージョンを切り替える手順｜shimの仕組みとビルド失敗の対処
• Pythonの@classmethodとは｜clsの役割とstaticmethodとの違い
• JITコンパイラとは？仕組み・インタプリタやAOTとの違いと主要言語の実装