窓の杜 wrote the retirement notice on September 25. The familiar Windows full installer is deprecated. From Python 3.16 it will not be offered. The replacement is Python Install Manager, following PEP 773, accepted in April 2025. The 3.14.7 installer already shows a warning that this setup program will not ship after 3.15.
PEP 773 is the English primary source. Traditional installer phased out by 3.16. Individual Windows Store versions stopped. Embeddable distro stays, but its listing on python.org download pages goes away and you get it through PyManager. NuGet is unchanged.
We already wrote that 3.15rc2 was the last candidate and the job was wheels. Today’s job is the Windows entry point those wheels sit on. If your README still says “download the 64-bit installer from python.org,” it is describing a file that is leaving.
The warning is already on 3.14.7
Impress photographed the 3.14.7 wizard. The banner is the news: this installer is scheduled to retire, and it will not be provided after 3.15. That is not a 3.16-only surprise. Anyone installing 3.14 from the old EXE this week is already in the sunset.
The old world was one EXE per version, plus one Store app per version through 3.13. The new world is one manager. Bare python on a Windows machine that has no Python opens the Microsoft Store page for Python Install Manager. Finish that install, run python again, and the manager downloads the current default. Impress’s default at writing time was 3.14. You do not pick a version in that first path. You get latest, then you learn py.
That is friendlier for a brand-new laptop and hostile for a CI image that assumed a silent EXE with a specific feature set. If your bootstrap still passes /quiet flags to python-3.x.y-amd64.exe, put a ticket on it. The flag set does not transfer to an MSIX manager just because both files live on python.org.
The py launcher that arrived with the full installer is deprecated in the same breath. PEP 773’s own timeline: existing .exe installer and py launcher deprecated and no longer released from two years after the PEP was accepted. The Store app is replaced with the install manager immediately. Those are different clocks. Do not assume the launcher EXE you rely on in a batch file lasts as long as 3.15 itself.
py install is the new README line
The discuss thread on PEP 773 is where Steve Dower repeats the download story people missed. PyManager ships as MSIX from the Store and from python.org. Double-click, same as the old habit, without the Store if you do not want it. Skip the Store and you skip automatic updates of the manager; update the manager yourself. You do not download a new installer for every Python release. The manager you already have picks up new versions. The example command is py install 3.16.
Impress documents the cousin commands that show up after the manager is in place. py exec -3.12 runs 3.12 for one invocation and fetches it if it is missing. py list shows what is installed and what the default is. PEP 773’s teaching split: python launches the default, py manages and can launch a specific version. Optional global python3.x commands exist if you add an extra PATH entry.
Put those four lines in the Windows section of the contributor guide:
- Install the manager once (Store or python.org MSIX).
py install 3.12(or whatever the project pins).py exec -3.12 -m pytestfor the versioned run.py listwhen a laptop disagrees with CI.
If the project still tells people to tick “Add python.exe to PATH” in a wizard that is going away, replace the screenshot. The PATH story is now an extra entry for python3.x, not a checkbox in WiX.
Offline machines get one concession in the PEP. The python.org package bundles a recent, unspecified CPython, so you can move the download to a box without internet and still have a runtime after install. “Unspecified” is the word to hate if you need a pin. For a pinned 3.12 on an air-gapped image, you still need a story for how py install gets the bits. Do not assume the bundled runtime is the version in your requires-python.
Why they will not keep the EXE
PEP 773’s rejected alternative is investing in the current installer. It sits on retired Windows Installer technology and an old WiX toolset that WiX is no longer improving. Migrating to newer WiX is a large project that still leaves CPython on a stack Microsoft is not developing. The Windows Installer features that caused pain, including accidental downgrades from collected file versions, were not even the features CPython needed.
That paragraph is why arguing for “just one more EXE” will lose. The maintainers are not bored of the wizard. The wizard’s foundation is gone. If you needed a corporate-blessed MSI, say so in a bug with the actual requirement (GPO, WSUS, a checksum in an allowlist). NuGet packages are explicitly unchanged. Some enterprise pipelines already came in through that door.
The embeddable distro remaining, but dropping off the download page, is the other migration. Tools that scraped python.org for the embed zip need to go through PyManager. If you vendor that zip in a game or a local plugin host, snapshot it now and write down the new fetch path.
3.15 is not the funeral
The Impress piece is about 3.16 not shipping the full installer. 3.15 is the last train for the old file, which is why the 3.14.7 warning names “after 3.15.” We already treated October’s 3.15 final as a wheel-building deadline. These two Octobers sit next to each other. Ship the 3.15 wheels. Then stop documenting the 3.15 EXE as the forever Windows path.
Do not uninstall the old launcher the same afternoon you read a Japanese news post. Do inventory:
- Docs and onboarding screenshots that show the EXE wizard.
- CI Windows images that
choco install pythonor curl an EXE. - Internal golden images that sysprep a specific
Python3xdirectory. - Teaching materials that say
py -3.11as if the launcher were eternal.
Chocolatey, winget, and company portals may already wrap PyManager. Check before you write a new bootstrap. The worst outcome is three installers in one README: EXE, Store, and MSIX.
Ruff will not save a broken interpreter pin. Neither will a linter rule that forbids python without a version. The manager’s default-latest first-run is convenient and also how a laptop silently leaves 3.12. Pin with py install and a versioned py exec in the scripts you actually run.
Store versus python.org is a policy choice
Impress shows the no-Python python command bouncing into the Store. That path is fine on a personal laptop. It is not fine on a locked-down corporate image that blocks Store, or on a build agent with no interactive session. Those machines want the python.org MSIX Dower described, or an internal mirror of it.
If Store is blocked and MSIX sideloading is also blocked, you are in the population the discuss thread worried about. Collect that as a fact for IT, not as a reason the PEP will revert. The intent in the PEP is immediate replacement of the Store app with the manager, and a phase-out of the traditional installer by 3.16. Plan against that intent.
Automatic updates are the trade. Store manager updates itself. python.org MSIX does not, unless you add a process. Old EXEs also did not update Python for you; you downloaded 3.12.4 by hand. You are not losing a great updater. You are gaining one manager to update instead of every interpreter.
Teaching and CI break on different days
A classroom that currently projects the EXE wizard can limp through 3.15. The break is the first lab that assumes 3.16 is “just another download.” Write the lab sheet now: Store or MSIX, then py install of the version the course pins, then py list as the screenshot students send when they are stuck. If the lab still says “check Add to PATH,” students will install two defaults and the wrong pip.
CI is earlier. GitHub-hosted windows-latest images will follow Microsoft’s Python layout, not your README. Self-hosted runners that curl python-3.12.x-amd64.exe from python.org will 404 when that file is gone. Change the curl this quarter, not the week 3.16.0 tags. If you pin a hash of the EXE in an allowlist, start hashing the MSIX instead, and decide who is allowed to bump the manager.
py exec -3.12 fetching a missing interpreter is convenient on a laptop and surprising on a runner with no network to python.org. Disable implicit fetch in that environment or vendor the manager plus the interpreter tarball. The PEP’s offline bundle is a recent CPython, not necessarily 3.12. Treat “unspecified” as “do not use this for a pin.”
Change the screenshot, keep the pin
The actionable piece for a Python shop this week is documentation, not a rewrite of the app. Replace the Windows install section. Name PyManager. Point at python.org for the MSIX, not a third-party blog. Show py install for the version in requires-python. Show py list as the debug step. Leave Linux and macOS alone.
Impress’s first-run story, where python becomes “install the manager, then install latest,” is the opposite of a pin. Latest on a random Thursday is how a typing change lands in a student project that still thinks it is on 3.12. After the manager exists, the next command in every doc should be the versioned install, not a victory lap.
If you teach undergrads, the Store bounce on first python is going to generate the same help-desk ticket in every lab. Write the two-command follow-up before the semester that ships 3.16. If you ship a Windows EXE of your own that bundles Python, the embeddable path is still there, just not on the front page.
NuGet remaining is the quiet exit for shops that never used the wizard. If that is you, this article is a notice that the download page your intern bookmarked is the one going stale, not a demand that you adopt py exec. Confirm the NuGet package versions you consume and keep them on the same pin cadence as Linux.
3.16 will not install from the wizard you memorized. The manager will. Put that in the README while 3.15 is still allowed to pretend otherwise. If the only Windows machine you own is a cloud runner, this is still your problem: the next person to clone the repo on a laptop will hit the Store bounce, and the issue they file will quote your screenshot of a wizard that no longer exists.
Discussion
Leave a comment
No comments yet
Be the first to start the conversation.