Yes, it goes back to 3.7, which is when the first (experimental) releases were made.
There are separate apps for each major version, and it won’t update between them (much to the Store/app model teams’ displeasure… but that’s our release model 
). But it doesn’t include builds after maintenance mode ends, it has exactly the same as what’s available to download on python.org, because they’re the same builds.
Ultimately, that’s not our responsibility. We’re already talking about an unideal situation, where the OP simply cannot use the most recent version of Python; thhis warrants a nice helpful cautionary note saying “this version of Python has not received updates since its release in ”, but it’s not our job to block people from installing old software on their computers.
To be fair, I’m not sure downloading and installing the Python.org releases directly is the most helpful thing for most novices to begin with, as opposed to using a tool or distribution (Conda, pyenv, Posy, Homebrew, package/environment managers, etc) that handles all that for them. With Conda, for example, using the latest security release of a feature version is as simple as conda install python=3.8 (or the graphical equivalent via Anaconda Navigator, IDEs, etc).
Steve can correct me on this since I’m no expert, but AFAIK there’s not really an easy way to “update” an existing installer-installed Python with one you built from source; they’re separate Python (I mean, maaaaaybe you could sometimes get away with just copying over files, but I shudder to even think of the potential problems that could cause). They’re effectively two separate Pythons.
The much easier alternative is just using Conda or another distribution…which is basically what Brett seems to be suggesting.
Of course, it goes without saying but the MS Store only covers Windows, so we’d want to also have equivalent options for other platforms if we go that route. It also has some known issues compared to the full installers and other Python distributions.
(7+ years, if you count starting from the first alpha and also the two releases that RMs sign up for)
I was paraphrasing Brett’s comment: “One thing to point out here is we
technically don’t want users downloading old versions of Python 3.8
just to get to the installer.” and losing some context.
So we’re in the situation that you can fetch (from python.org) an
installer for a version lacking published security fixes but there still
doesn’t seem to a path forward from there which isn’t a
build-from-source.
For Windows that’s ok since I now understand that there are versions
from 3.7 on available from the MS Store (including the security fixes
Steve? I’m imagining so).
Can we not suggest that path to end users, at least for Windows?
Unless you “lie” and put in the same identifier we use for releases (which is actually the default… so… shouldn’t be that hard). But yeah, you’d uninstall our build and install your own.
You mean like apt install python and yum install python? 
The main difference here is that the Microsoft Store lets us manage our own package, rather than delegating that work to a different set of volunteers (who may or may not overlap with “us”, but we don’t really have any recourse to “claim it back”).
Only the security fixes that make it in during maintenance period. Source-only releases don’t get released to the Microsoft Store, for all the same reasons we don’t publish binaries to python.org.
This feels like a very extreme (and worrying) response. The reaction to “it’s quite hard to find the latest installer for a given version of Python” is “we should stop distributing binaries and direct the user to 3rd party distributions” - really? When the most well known such distribution (conda) is incompatible[1] with the standard ecosystem for distributing packages (pip, PyPI, etc)?
I hope any attempt to make such a massive breaking change to the ecosystem would need at least a PEP and a long transition period.
Maybe I’m over-reacting to what’s being said here. But surely it’s not unreasonable to simply consider improving the existing webpages, rather than immediately jump to discussing alternative suppliers of Python?
OK, semi-compatible… ↩︎
This reaction was only for when the given version is a security-fix only release (i.e. the binaries are not on python.org at all).
It bleeds a little bit into earlier stages for users who might know they’re going to need extended support. They would be better off starting with a supplier who is going to supply binaries for security-fix only releases. Though in my experience, most users wouldn’t ever put themselves into this category - they’ll assume that upgrading is easy (or that we’re going to supply binaries forever).
Yeah, we agreed on fixing the docs already. Just need someone to do it. The discussion since then is getting into narrower and narrower spaces.
OK, thanks for the clarification. I don’t see any problem with python.org just distributing the last installer-based release, maybe with a note that “subsequent security fix releases were only provided in source form”.
Personally, I think it’s pretty clear already that python.org distributes versions that don’t come with any support guarantees. Anyone wanting paid for extended support should be looking elsewhere anyway. And anyone wanting free extended support is missing the point of open source 
Right; that’s kinda what I meant by “equivalent”—though, that’s already the case with any release for Linux, I guess, since there is no official installer other than the source tarball? I suppose we could develop a Flatpak/Snap, maybe? But that’s getting a little tangential.
Not really if used just used to install Python itself rather than Python-speciifc packages, which is the context here—i.e. conda create -n pyXY-env python=X.Y, then pip install from there. Used that way, its essentially no less compatible than any other Python distribution, and almost certainly much more “pure”/consistent with Python.org Python than almost any Linux distro’s Python.
Not that I’m saying I necessarily think we should explicitly recommend it there or anything, but I did want to clarify that point.
I don’t disagree there, and had some detailed suggestions to that end above. At the same time, others raised the point that we don’t want to be actively encouraging users to either use a version of Python with known security vulnerabilities, or expecting regular users (especially on Windows/macOS) to build from source. And I at least was replying to a specific question asking about the clearest and easiest path for newer users like the OP here.
I knew someone would make that point. But my point isn’t about technical details like that, it’s about the fact that beginners looking on python.org are likely coming from a situation where they are learning Python as a result of “stuff on the internet”, or from a course that doesn’t instruct them to install conda. Those people will be hopelessly confused when they find that they’ve installed an ecosystem where all of the “stuff on the internet” is not recommended practice. I know this is the case - a colleague of mine learning Python went through exactly this and dumped conda as “impossible to understand”. Luckily he had me to ask, otherwise he may have dumped Python altogether…
This is just the “Python packaging strategy” discussion spilling over into other areas, though. So I’d rather that for this thread, we just stuck to improving the information people need to get Python installed, and left the “how Python should be distributed” debates for the (many) other threads they are already being discussed on.
I want to revive this topic. It is a fact that sometimes users have to use Windows, and sometimes they have to use old versions of python.
The two “reasonable” ways I see to install python on Windows are (1) through an installer (the same way typical users install most everything on Windows) or (2) via anaconda. Route #2 is not desirable because now beginners, who want to learn python now have to learn this other thing. What is anaconda? Why do I need it? what is an environment?
This means that the “I am on Windows and I want to install Python” will usually end up in the box labelled “find an installer for Python”. Python.org looks pretty official and has a downloads page that seems to have installers for Python, so it seems like a good place to look. Unfortunately if you’re looking for an old version you’ll need to scroll or search past all of the newest security releases of the old versions to find the newest version that has an installer.
This is annoying, and lots of people in this position probably don’t even know what a security release is.
Perhaps this state of affairs has come out because people writing the page are unfamiliar with the windows workflow where using an installer is the only way that you install things on Windows (for a huge percentage of users)?
Anyways, I think the solution was hit on above. But I would want something like one of the following:
The can be messages on all patch versions which have more recent security fixes indicating the danger of using these versions.
It’s unfortunate that some users will be funneled into using versions of python which don’t have the latest security fixes, but this result appears from the following constraints:
It’s unfortunate the users will be using these old minor/patch versions that don’t have the most recent security fixes. But it’s a fact that it happens and it is already possible to do through python.org. It’s just hard/annoying to do so. Making it easier to do this will help more users than it will hurt in my opinion and feels like the lesser of the different evils:
I’m not sure if the solutions above were agreed upon already or not. If not, I urge that making it easier to access these binaries would help people. If so, it sounds like it’s just a matter of someone having the bandwidth to make the changes to the webpage?
I absolutely agree that the information should be better organized and better presented. But why do beginners need to install older versions? If it’s “because such and such heavyweight AI library doesn’t have a wheel for 3.12 yet” then someone is teaching in a very wrong order.
As the OP, I was trying to offer a new user a slightly old Python to side step a library which seemed not happy with the latest revision, not a pure Python library but Qt6 which was possibly sensitive to the binary API or simply not yet released for the latest version at the time.
While it’s true that the download page could be made more user friendly with a few drop-downs and buttons to select the version you want to see, there are alternatives available, specifically for Windows:
Note: This list not necessarily exhaustive.
The downside with most of these for older Python versions is that you only get the latest released version with a Windows installer (as Brett already mentioned earlier). E.g. for Python 3.9 that would be 3.9.13, not the latest version with all security fixes, which is 3.9.19 (as of today).
The only versions that really are up to date with the lastest patch level security release are Miniconda and the unofficial installers. I’d always recommend going with an installer that provides these latest security fixes, even if they are not fully open source.
Updated on 2024-05-20: Add a more explicit warning about using unofficial installers.
On the python.org main page in the “Downloads” menu there is a convenient big nice button that directly downloads a specific installer:
A similar button is on Download Python | Python.org which also directly downloads a specific installer:
I think adding a similar button to the top of Python Releases for Windows | Python.org would be great,
and even better would be adding ~5 buttons, one per supported minor version as an easy way to find the recommended Python 3.11 for example.
Horrible mspaint mockup:
Three reasons I have in my experience:
The people coming into the use of these tools/systems come in at all different levels of Python/software skills so it’s not really something where “only advanced users need to install old versions of python”. It might be a brand new python user being told to install our camera control wrappers onto their computer so they can run some automated testing in the lab.
So from the perspective of a “principled pythonista” it’s probably the case that work could be done to bring all this code to run on python 3.12. But it would take a lot of time and money to do so, and it’s really not a priority. It’s much easier to just tell people to install an old version of python.
- The Windows Store - When you search for Python you get all recent Python versions with a single entry per minor version
Many of the computers we need to install on are not networked. Windows store is not an option.
- Chocolatey with one of the available UIs - Similar to the Windows Store, but slightly less user friendly
Never heard of this. Seems annoying to bring on an extra tool just to work around Python.org being hard to navigate.
- The Miniconda download page - One link per version for several recent Python versions
Perhaps. I’m really not a fan of conda because it requires users and supporters to learn and understand ANOTHER THING in addition to python. It also gives people this strange impression that they need conda to run python which simply isn’t true. I guess the fact is that, for some users and some workflows, conda can make environment management easier but I haven’t found that to be the case personally or with others I’ve worked with.
- The unofficial Python Windows installers page - These are maintained separately by a single developer
It’s ok, but now users need to have git and be able to clone from github. Or maybe nuget needs to be installed? Remember, we’re Windows users. We’re want to go to a webpage, click a download link, have a prompt say “would you like to install …”, click OK a bunch of times on different prompts, and then have the thing installed.
- The Python FTP downloads page - Comes with a familiar directory listing interface; slightly geeky perhaps, since you need to know which file to downloads (you typically need to use the python-3.x.x-amd64.exe files)
This “you need to know which file to downloads” is the exact same issue as Python.org.
edit: sorry, it has the same issue which is that not all 3.x.y versions (including the newest patch version y of a given minor version x) have .exe Windows installer files so you have to flip through many versions to find the right one.
So looking through all of these alternatives, it really feels to me like I still want to get old versions of python from Python.org and for the 3.x.y versions that have installers to just appear prominently somewhere on the Windows downloads page.
No, you can download the installers straight from the Github page. Once downloaded, the experience is that same as for the official installers, except that you get more recent code on Windows.
Ok fair. That one is a pretty good option. I’ll test it out. But it does look like a newcomer could pretty easily be given instructions to that page and how to find the installer for the Python version they care about.
It’s arguably a big upside that installers are maintained for latest patch versions. Single maintainer is a downside.
Good to know about this alternative, but like you said at the top of your post, it would still be good to make it easier to access old installers on Python.org.
I wonder if the author of the unofficial installers would be willing to work with the Python team and Python.org so those unofficial installers could just become official installers for the latest patch releases for old versions….
