PythonWindows fills the gap python.org leaves for security-only Python

The gap is an installer, not a source tarball

Python's release policy produces an awkward situation on Windows, and this repository exists to work around it.

The README states it plainly. For older Python versions in the security maintenance status, python.org officially releases only the source code and no installers. The question the project asks is what you do if you want an easy way to install these versions on Windows, and the answer is that here you can obtain unofficial Windows installers for security updates of Python 3.5 and higher.

The reason for the policy is not a mystery. A Python release in security-only maintenance receives fixes, not features, and building and signing a Windows installer for it is work that the core team has limited reason to do. But the population still running those versions does not go away. A line that reaches security-only status is a line that many enterprises are still on, often because an application pins it.

So the shape of this project is a build pipeline, not a library. The repository is mostly documents and patches, and the artefacts live in the GitHub releases. The top level contains CHANGELOG.md, LICENSE.txt, Notes.md, a patches/ directory and the usual repository files, and the project history is recorded in the changelog.

The audience is specific: someone on Windows who needs a specific old Python and cannot use the source distribution. It is also worth being clear about what it is not. This is not a fork of Python, not a patch series that changes the language, and not a distribution channel with its own package index. It is a set of builds of the official source, and the trust question that comes with that is discussed below.

Three artefact shapes per version, and one that stopped at 3.10

Each Python version in the repository is published in a fixed set of shapes, and the list in the README is the specification of what you get:

- AMD64 executable installer (e.g. python-3.5.5-amd64-full.exe)
- x86 executable installer (e.g. python-3.5.5-full.exe)
- ARM64 executable installer (e.g. python-3.11.10-arm64-full.exe) (since 3.11)

Below the installers come the embeddable zips for AMD64, x86 and, since 3.11, ARM64, then the NuGet packages under the names python, pythonx86 and pythonarm64, and finally a Windows help file, which the README marks as being for 3.5 to 3.10 only.

The architecture coverage is the detail that decides whether the repository is useful to you. AMD64 and x86 exist for every version, so a 32-bit application that still needs Python 3.5 can be served. ARM64 exists only from 3.11, which matches the point at which Windows on ARM became a real deployment target. If you are on ARM64 and need 3.9, this repository cannot help you.

The three artefact shapes serve different consumers, and it is worth knowing which one you need. The executable installer is the ordinary double click installation, with the full set of components. The embeddable zip is the small footprint variant, the one you unpack next to an application that has its own interpreter expectations. The NuGet package is the one a build system consumes, and the README treats it separately with its own instructions.

The help file is a leftover from the era when Python shipped a compiled documentation file on Windows, and it stops at 3.10 for that reason.

The NuGet install differs between Command Prompt and PowerShell

The NuGet section is the one part of the README with a procedure, and the procedure differs by shell because the source directory is expressed differently in each.

The instructions start with a prerequisite: have the NuGet Command Line Interface installed, go to the directory containing the .nupkg file, and replace the placeholder target\installation\directory in the commands with the location you want the package installed into.

In Command Prompt, the two commands are:

For 64-bit Python, run `nuget install python -Source %cd% -OutputDirectory target\installation\directory`

For 32-bit Python, run `nuget install pythonx86 -Source %cd% -OutputDirectory target\installation\directory`

In PowerShell the same two commands are written with the location substitution instead of the %cd% variable:

For 64-bit Python, run `nuget install python -Source $(Get-Location) -OutputDirectory target\installation\directory`

For 32-bit Python, run `nuget install pythonx86 -Source $(Get-Location) -OutputDirectory target\installation\directory`

The package names matter as much as the shell. The 64-bit package is python, the 32-bit one is pythonx86, and from 3.11 there is a third, pythonarm64. The Source argument points at the current directory, which is how the local file is found rather than a remote feed, and the OutputDirectory argument is where the extracted package lands.

One detail to keep in mind when you read the README, because it is easy to miss. The instruction is to replace the placeholder path, and the two shells show the same placeholder with a different way of expressing the current directory. A copy and paste without that substitution will either fail or land somewhere you did not intend.

Built from the official sources with patched build scripts

How the artefacts are produced is the part that determines whether you should trust them, and the README is direct about it.

The installers were built from the source distributions published at the python.org source downloads page, patched to fix some bugs in the build scripts and to include all components to allow for a fully-offline installation.

Three things follow from that sentence. First, the starting point is the official source distribution, so the interpreter itself is not modified in any way that the upstream project did not already ship. The changes are to the build scripts, which is the layer that turns source into an installer. Second, the offline requirement is a deliberate addition: the standard installers fetch some components from the network, and a patched build bundles them so the installation works on a machine with no internet access, which is exactly the situation a locked down enterprise environment is in. Third, the build scripts had bugs that had to be fixed to produce a working installer at all, which is a reasonable expectation for a build path that upstream no longer exercises for those releases.

The repository holds the patches in a patches/ directory at the root, and the README points technical readers to Notes.md for further information about how the installers were built and how you may build them yourself. That second half matters: the project is describing a reproducible build rather than asking for blind trust in a binary.

For a reader evaluating the project, Notes.md is the document to read first. It is the place where the build procedure, the patches and the deviations from the upstream scripts are described, and the README itself defers to it.

Official binaries where they exist, these builds only where they do not

The sensible comparison is with the official python.org Windows installer, and the difference in approach is precise rather than a matter of quality.

The official installer is built and signed by the Python Software Foundation, published for the versions that are in active or bugfix maintenance, and comes with whatever support that implies. It is the default answer for any version where it exists.

These installers are built by a third party from the same source distributions, for the versions where the foundation publishes no binary at all. The approach difference is therefore about who does the packaging work, not about which interpreter you end up running. The Python you get is the Python upstream published.

There is a second, less obvious comparison worth making, against the embeddable zip that python.org itself publishes for current versions. If all you need is a small interpreter to sit next to an application, the official embeddable zip already does that for supported versions, and it carries the foundation's own build. The reason to use the versions here is the same reason for everything else in this repository: your version is too old to have an official artefact.

A third path exists for some cases, and it is the one to consider first if you are free to choose. Move to a supported Python version. Everything in this repository exists because a deployment is stuck, and the version being in security-only maintenance means the fixes you get are fixes to a runtime that is no longer gaining features or performance work.

The pragmatic ordering is: use the official installer if your version has one, use these builds if your version does not and you cannot change it, and treat staying on the old line as a separate decision from being able to install it.

Licence, release cadence and the trust question

The files are provided under the MIT licence, with the text in LICENSE.txt at the repository root. MIT is a permissive licence and it covers the artefacts in the releases, which is worth noting because it is what makes redistribution by a third party straightforward in the licensing sense.

The release cadence follows upstream Python's own security cadence rather than a schedule of its own. The three most recent releases are v3.12.15, v3.12.14 and v3.12.13, all published on 2026-10-01 within a few minutes of each other, and the last push to the repository was on the same day. The README also links the current patch level for every maintained line, from 3.12.15 down through 3.11.17, 3.10.22, 3.9.25, 3.8.20, 3.7.17, 3.6.15 and 3.5.10.

That pattern of several tags in one minute is the signature of a bulk build. When a security release lands upstream across many versions at once, the builds for each version appear together. It also means there is no meaningful distinction between the tags, so you should pick the version you need rather than the newest tag.

The trust question is the one to be honest about. These are unofficial builds of a security maintenance release, and the person using them is usually doing so because a security fix is exactly what they need. The mitigation is transparency rather than authority. The source is the official one, the build patches are in the repository, the build procedure is documented in Notes.md, and the project history is in the changelog. A reader can reproduce the build instead of taking the binary on faith.

What the project cannot offer is a vendor signature, a support commitment, or any guarantee that a given enterprise policy will accept an installer from an unaffiliated source. For a locked down environment, that last point is often the real blocker, and it is one no amount of documentation in this repository removes.

Editorial conclusion

Adopt PythonWindows if you are on Windows and pinned to a Python version that is in security-only maintenance, and you need an installer, an embeddable zip or a NuGet package rather than a source tarball. Do not adopt it for a version that python.org still ships as a Windows installer, since the official binary is the one to use, and do not adopt it where a signed, vendor supported installer is a procurement requirement, because these are explicitly unofficial builds. Before you install anything from here, read Notes.md, confirm the artefact you pick matches your architecture, and decide whether the security fixes in the release notes are the reason you need the version at all, because staying on an old line to avoid an upgrade is a separate decision from being able to install it.

Frequently asked questions

Official sources

1. adang1345/PythonWindows on GitHub
2. Issues
3. License: MIT
4. README
5. Releases