Python 3.15 on Windows: which packages install (tested)

Python 3.15.0 came out on October 9, 2026, and Python 3.10 reaches end of life on October 31. Python itself installs fine. The trouble is the packages: until a package publishes a ready-made build (a wheel) for 3.15, pip downloads the source code and tries to compile it. Most Windows machines have no compiler, so that’s where installs break.

I installed 45 of the most-used packages on Windows 11 with Python 3.15.0, each in a fresh virtual environment, then did the same with Python 3.14.5. On 3.14 all 45 installed. On 3.15, 37 did and 8 didn’t. Two of the 8 have since fixed it. torch 2.15.0 ships a 3.15 Windows wheel (re-tested October 30), and so does sentencepiece 0.2.3 (released and re-tested November 5). So 6 still fail:

Package	On Python 3.15 (Windows)	Why
torch	Installs since 2.15.0 (re-tested Oct 30). With 2.14.1: `Could not find a version that satisfies the requirement torch (from versions: none)`	2.14.1 had no 3.15 builds; 2.15.0 does
tensorflow	`… requirement tensorflow (from versions: none)`	No 3.15 builds at all
pyyaml	`Microsoft Visual C++ 14.0 or greater is required`	No 3.15 wheel, so pip compiles it (fix without a compiler)
transformers, tokenizers	the same Visual C++ error, from pyyaml	They need pyyaml (through huggingface-hub)
sentencepiece	Installs since 0.2.3 (re-tested Nov 5). With 0.2.2: `[WinError 2] The system cannot find the file specified`	0.2.2 had no 3.15 wheel, so pip tried to build it; 0.2.3 has `cp315-win_amd64` and `win_arm64` wheels
jupyterlab	the same Visual C++ error, from pyyaml	Needs pyyaml (pywinpty, the other blocker, got a 3.15 wheel on Oct 15)
langchain	`Encountered error while generating package metadata.` → `uuid-utils`	No 3.15 wheels for `uuid-utils` (Rust), `zstandard` and pyyaml, so pip compiles them. `ormsgpack`, the old blocker, got a 3.15 wheel on Oct 15

These installed on 3.15 with no trouble: numpy 2.5.4, pandas 3.0.6, scipy 1.18.1, matplotlib 3.11.2, pillow 12.3.0, scikit-learn 1.9.1, polars 2.0.0, pyarrow 26.0.0, numba 0.68.0, opencv-python 5.0.0.93, safetensors, requests, httpx, aiohttp, fastapi 0.143.0, pydantic 2.14.1, uvicorn, django 6.1.2, flask, sqlalchemy 2.1.4, psycopg2-binary, psycopg 3, asyncpg, lxml, cryptography 50.0.2, orjson, regex, msgpack, psutil, grpcio, greenlet, gevent, pyzmq, openai 3.29.0, anthropic 1.13.0, mypy 2.4.0 and black.

Is it Windows, or Python 3.15?

Both. To separate them, I ran the failing packages on GitHub’s Windows and Ubuntu runners too. Those come with a C++ compiler and Rust already installed. There, pyyaml, transformers, sentencepiece, jupyterlab and (since October 16) langchain did install on 3.15, because pip could compile what was missing. So for those five, the real problem on a normal Windows PC is the missing compiler.

Two failed everywhere, compiler or not: torch and tensorflow (there’s nothing to compile, they simply weren’t published for 3.15). torch 2.15.0 now is, for Windows, Linux and macOS; tensorflow still isn’t (re-checked October 30). Until October 15 langchain did too, because of a PyO3 version check in ormsgpack; see below.

The fix for most projects: create the venv with 3.14

If a project depends on any of the 8, keep it on 3.14 for now. With the Python install manager, pick the version when you create the environment:

py -V:3.14 -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt

PyYAML, and transformers with it

PyYAML 6.0.3 is from September 2025, so it has Windows wheels up to 3.14 and none for 3.15. Without a compiler, pip fails:

error: Microsoft Visual C++ 14.0 or greater is required. Get it with "Microsoft C++ Build Tools": https://visualstudio.microsoft.com/visual-cpp-build-tools/
ERROR: Failed building wheel for pyyaml

pip install transformers fails with the same lines, because it needs PyYAML too. (This error has other causes as well, such as old pinned versions and 32-bit Python: all four, tested.)

PyYAML can build without its C speedups. Turn them off for the install:

$env:PYYAML_FORCE_LIBYAML = "0"
pip install pyyaml

This version is pure Python, so reading and writing YAML is slower. For config files you won’t notice; for large YAML files, use 3.14 until PyYAML ships 3.15 wheels.

PyTorch: fixed in torch 2.15.0

With torch 2.14.1, the latest release when I first tested, pip on 3.15 said:

ERROR: Could not find a version that satisfies the requirement torch (from versions: none)
ERROR: No matching distribution found for torch

“from versions: none” means PyPI has no torch at all for this Python version. (32-bit Python and old CUDA index URLs give the same error: every cause, tested.) The same happened on Linux. TensorFlow gives the identical error and I found no way around it, so TensorFlow projects need 3.14.

torch 2.15.0 is the first stable release with Python 3.15 wheels. If you still get the error, pip is picking an older pin or an index without it; a plain install gets 2.15.0:

pip install --upgrade torch

For GPU builds on 3.15, the cu132 index has torch 2.15.0 (--index-url https://download.pytorch.org/whl/cu132). Before 2.15.0, the only way was PyTorch’s nightly index, which installed 2.16.0.dev20261012+cpu on October 13.

langchain: “newer than PyO3’s maximum supported version”

langchain needs ormsgpack, which is written in Rust using PyO3. Up to 1.12.2 there was no 3.15 wheel, and building it failed even with Rust installed:

error: the configured Python version (3.15) is newer than PyO3's maximum supported version (3.14)
ERROR: Failed building wheel for ormsgpack

The message suggests a way around the check: setting PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1.

With ormsgpack 1.13.0 out, I ran pip install langchain on 3.15 again. On this PC (no compiler, no Rust) it now stops at uuid-utils, a Rust package that langchain-core needs and that has no 3.15 wheel:

error: metadata-generation-failed

× Encountered error while generating package metadata.
╰─> uuid-utils

zstandard and pyyaml have no 3.15 wheels either, so they need the C++ compiler. On GitHub’s Windows and Ubuntu runners, which have both a compiler and Rust, langchain 1.4.6 installed on 3.15 with ormsgpack 1.13.0 from a wheel and those three built from source.

So on a normal Windows PC, the fix is still to create the project’s environment with 3.14:

py -V:3.14 -m venv .venv

If you need 3.15, install Visual Studio Build Tools (the “Desktop development with C++” workload) and Rust first; then pip install langchain can build the three missing packages.

sentencepiece and jupyterlab

Until November 5, sentencepiece needed a compiler on 3.15: 0.2.2 had no 3.15 wheel, so pip built it from C++ source, and on Windows that failed with [WinError 2] The system cannot find the file specified. sentencepiece 0.2.3, released November 5, ships wheels for Python 3.15 on Windows (x64 and ARM64, plus the free-threaded cp315t build).

Install the latest sentencepiece (0.2.3 or later), and forbid compiling so pip can’t fall back to a source build:

pip install --only-binary=:all: sentencepiece

jupyterlab also depended on pywinpty, a Rust package with no 3.15 wheel. That changed on October 15: pywinpty 3.1.0 ships a Windows wheel for 3.15. Now jupyterlab only needs PyYAML.

Use the PyYAML switch from above, then install jupyterlab:

$env:PYYAML_FORCE_LIBYAML = "0"
pip install jupyterlab

Upgrading from Python 3.10 to 3.14: what broke

Everything above is about 3.15. If you’re leaving 3.10 for 3.14 instead, four versions of removals pile up in between. I ran a set of snippets that were ordinary on 3.10 under Python 3.10.11 and 3.14.5 on Windows 11 (October 13), plus a 3.10-era requirements.txt. On 3.10 they ran; on 3.14 these broke:

3.10-era code	On Python 3.14
`import distutils`	`ModuleNotFoundError: No module named 'distutils'`
`import imp`	`ModuleNotFoundError: No module named 'imp'`
`import asyncore`	`ModuleNotFoundError: No module named 'asyncore'`
`import cgi`	`ModuleNotFoundError: No module named 'cgi'`
`import telnetlib`	`ModuleNotFoundError: No module named 'telnetlib'`
`from typing.io import TextIO`	`ModuleNotFoundError: No module named 'typing.io'; 'typing' is not a package`
`from configparser import SafeConfigParser`	`ImportError: cannot import name 'SafeConfigParser' from 'configparser'`
`ssl.wrap_socket(...)`	`AttributeError: module 'ssl' has no attribute 'wrap_socket'`
`ast.Num`	`AttributeError: module 'ast' has no attribute 'Num'`
`pkgutil.find_loader(...)`	`AttributeError: module 'pkgutil' has no attribute 'find_loader'`
`self.assertEquals(...)` in tests	`AttributeError: 'T' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'?`
`asyncio.get_event_loop()` at the top level	`RuntimeError: There is no current event loop in thread 'MainThread'.`

Two more only warn on 3.14, so they’ll break later: datetime.utcnow() (“deprecated and scheduled for removal in a future version”) and locale.getdefaultlocale() (“slated for removal in Python 3.15”). On 3.10, imp and asyncore already printed a DeprecationWarning saying they’d go in 3.12. If your logs hide warnings, this list is the first you’ll hear of it.

Removed modules: replace them, or install the backport

For most of them, the standard library has a replacement. Each of these ran on 3.14:

Instead of	Use
`imp.reload(m)`	`importlib.reload(m)`
`SafeConfigParser`	`ConfigParser`
`ssl.wrap_socket(...)`	`ssl.create_default_context().wrap_socket(...)`
`ast.Num`	`ast.Constant`
`pkgutil.find_loader(name)`	`importlib.util.find_spec(name)`
`self.assertEquals`	`self.assertEqual`
`datetime.utcnow()`	`datetime.now(datetime.UTC)`

When the import is inside a dependency you can’t edit, these PyPI packages put the old module back:

pip install setuptools legacy-cgi standard-telnetlib standard-asyncore

For distutils errors that come from node-gyp during npm install, or from distutils.msvccompiler, see No module named ‘distutils’.

asyncio.get_event_loop() now raises

Scripts that start with loop = asyncio.get_event_loop() and then call loop.run_until_complete(...) worked on 3.10. On 3.14 they fail with the RuntimeError above.

Let asyncio.run() create and close the loop:

import asyncio

async def main():
    ...

asyncio.run(main())

Old pinned versions don’t install on 3.14

A requirements.txt from the 3.10 days pins versions that predate 3.14. pip finds no ready-made build, tries to compile, and the old build scripts fail on new Python (installed one at a time into a fresh 3.14 venv with pip 26.1.1):

Pin	On Python 3.14
`numpy==1.24.4`	`BackendUnavailable: Cannot import 'setuptools.build_meta'`
`PyYAML==6.0`	`AttributeError: 'build_ext' object has no attribute 'cython_sources'`
`pandas==1.5.3`	`ModuleNotFoundError: No module named 'pkg_resources'`
`requests==2.28.2`	installed (pure Python, nothing to compile)

Upgrade the pins for anything with compiled code. Change == to >= for those lines, then let pip pick versions built for 3.14:

pip install --upgrade numpy pandas pyyaml

numpy 2 and pandas 2 or 3 are major upgrades with their own breaking changes (on November 2, the versions pip picked for 3.14 were numpy 2.5.4 and pandas 3.1.0), so run your tests after this step. If you can’t take those yet, stay on a Python those pins support, but then you’re back on an unsupported Python.

The 3.10 → 3.14 checks ran on Windows 11 Pro on October 13, 2026, with Python 3.10.11 and 3.14.5 from python.org through the Python install manager, side by side. Each snippet ran in a separate process on both versions; the fixes and backport packages ran in a fresh 3.14 virtual environment. On November 2, every row was re-run on Python 3.10.22 and 3.14.9 on GitHub Actions ubuntu-latest: all twelve snippets ran on 3.10 (some with a DeprecationWarning) and failed on 3.14 with the messages above; the replacements, the four PyPI backports and asyncio.run() worked on 3.14; numpy==1.24.4, PyYAML==6.0 and pandas==1.5.3 failed to install while requests==2.28.2 installed; and current numpy, pandas and PyYAML installed from wheels only. The script and output are public.

How this was tested

Windows 11 Pro (build 26300), Python 3.15.0 and 3.14.5 from python.org through the Python install manager, on October 13, 2026. Each package was installed into a fresh virtual environment, first allowing only wheels, then with a normal pip install for any that failed. This PC has no C++ compiler and no Rust, like most Windows machines. The compiler checks ran on GitHub Actions’ windows-latest and ubuntu-latest runners with Python 3.15.0 and 3.14; the workflow and script are public. Every error above is the real output. On October 30 I re-tested on Windows 11 with Python 3.15.0 (NuGet build) and pip 26: torch 2.15.0 and pywinpty 3.1.2 installed from wheels; pyyaml and tensorflow still gave (from versions: none) with wheels only. On November 5, after sentencepiece 0.2.3 came out, a fresh Python 3.15.2 on GitHub’s windows-latest runner installed it with compiling forbidden, imported it, and refused 0.2.2 the same way (the run).