I have a huge problem. Why is there no Python after 3.8 for Windows7?
See https://docs.python.org/3/using/windows.html: âAs specified in PEP 11, a Python release only supports a Windows platform while Microsoft considers the platform under extended support. This means that Python 3.11 supports Windows 8.1 and newer. If you require Windows 7 support, please install Python 3.8.â
You can find some options here: Software based on Python 3.9 is not working on Windows 7 - Stack Overflow. Note these are not supported by the CPython community.
I have three solutions for you.
- Use Python 3.8 on Windows 7 and accept that some Python programs wonât work
- Upgrade to a supported version of Windows and then install a newer Python into that
- Upgrade to Debian Linux.
All of them have consequences. Itâs your job to decide which one solves the most problems while creating the fewest. Without any further information about what your problem IS, all we can do is answer the simple part of your question: There is no Python 3.11 for Windows 7 because Microsoft no longer supports Windows 7, and the policy is to build for the Windowses that are actually supported.
I donât have the permissions to fix it currently, but the Packaging
category isnât the right place for this, as it is about packaging Python projects; this should be in the Python Help
category instead.
Already discussed here among other threads
Also, a key point to note is that Python feature versions released before a given OS was end of life still support that OS for their own lifetime (1.5 years of bugfix support and 5 years of security support), even if that OS goes EOL during that period, so you effectively get up to 5 years of (security) support after your OS EoLs. Thatâs a pretty good deal for free, Iâd say.
A little off topic, but note that Debian is probably not a good choice if youâre looking for the latest Python (at least not stock), as it prioritizes stability and the latest Debian stable only comes with 3.9, one version later than 3.8 (of course, you can install your own, but that takes a bit more effort). Additionaly, the Debian Python story has numerous issues and compromises by default. Finally,m itâs probably also not the best choice for a Windows user thinking of migrating to Linuxâother distros, like Ubuntu, cater much more to that.
True. That said, though, the vast majority of people who ask this sort of question have already mentally dismissed Linux as an option, despite it being, in truth, exactly like any other option: a particular set of compromises, a particular set of offerings.
Sadly, a lot of people start out with an assumption that theyâre acting under restrictions, when the truth is that most of those restrictions are consequences of other decisions. And while that might be a difference without a distinction in some cases (is âI live in {some country} and thatâs illegal hereâ a restriction or a decision?), it is most definitely worth revisiting other decisions (like choices of operating system, Python version, etc), and none of us are qualified to do that as we donât know the whole story.
And really, its close to the same deal with upgrading their OS, as is the case for this user. I know I for one stayed on Win 8 on the same (upgraded) machine for a full decade, all the way until the recent EoL, not because I like it (I hated it; it was the worst of both worlds between Windows 7 and 10) but because Iâd invested 10 years and hundreds of hours installing and configuring it and all my applications to be stable, secure, (reasonably) private and work exactly the way I wanted.
And by the end, it hardly mattered what OS I was using as I had Git Bash, Cgywin, Linux VMs, Choco, both the *nix and Windows native build toolchains installed and a 4GB Raspberry Pi 4 with Fedora and Debian as a second machine, and I was spending far more time in the applications Iâd installed, learned and configured (for some of which, like ConEmu and MultiCommander, for which Iâve still found no similarly featured and usable Linux equivalents) rather than interacting with the OS itself.
Even migrating to Win 10 was a long and complex process (the tail end of which was still ongoing) since I couldnât just spend a week or two away from everything upgrading cold turkey, especially having accumulated a fair share of cruft over 10 years, and instead ended up having to spin up a parallel install on a separate identical machine and then cut over once it was finally fully set up and ready for production.
I think Iâve expressed myself in the wrong way. I donât want any support, neither from Python nor from Microsoft. I didnât talk about support anywhere either. I talk about a ban.
I just want to be allowed to install Python. You make yourselves here the vassal of Microsoft and forbid it to me.
I want to know why you forbid me to run Python on Windows7.
Everything else is nonsense.
What âbanâ are you talking about, exactly?
Anyone, including you, is welcome to download the Python source and build and run it on Windows 7 or any OS they want, EOL or notâjust install a compatible version of the MSVC compiler, run the build script and ban, youâve got Python. Of course, with newer versions you might need to patch some newer things that donât work on older Windows, but that would be âsupportâ not a âbanâ.
Yep. Itâs so true. And often, staying on an OS and version that youâre comfortable with is the right choice. But itâs still a choice, and has to be weighed against the other choices.
Nobody is banning you from installing Python on Windows 7, or Windows 95 if you like, or a 1986 MacPlus. Go right ahead. Python is open source software, feel free to download the source code and compile it for whatever operating system you want.
Just remember that you donât want any support to get it working.
If you are not paying people to develop Python, you donât get to order them around and demand that they support the platforms you want. You arenât their boss, or their paying customer, and nobody owes you Python 3.11 for Windows 7 for free.
When youâre accustomed to privilege, equality feels like oppression.
Instead of demanding why weâre âforbiddingâ you to run Python 3.11 on Windows 7, why not instead ask: Why are you demanding that the Python core devs test every new version of Python on all the old versions of Windows? Remember, youâre here asking about Win 7, but someone else will be asking about Win 8, another person will want XP, and thereâs probably someone still running 98SE out there. Is it reasonable to demand that the Python developers test their code on all of those versions?
Remember that supporting old Windowses is work and someone has to do that work. Supporting current Windows is work too, but itâs work that benefits a lot more people.
Download the source code for Python. Download a C compiler. Build it yourself. Or find someone whoâs willing to do that for you, possibly for $50/hour or more.
Insulting people is not a good way to get them to do things for you.
You would have to patch the source code to support Windows 7, more so with each subsequent release after 3.8. I donât think itâs a lot, but youâll need some familiarity with C. A recent example is that in 3.12 os.getppid()
now uses the process snapshot API, which is simpler and more efficient than the previous implementation based on the toolhelp API, but it requires Windows 8.
For Windows 8.1 users, note that Python 3.12 will only support Windows 10/11. I donât know whether the installer will make that a rigid requirement â probably not â but you should still be able to build for Windows 8 without having to patch the source.
Yeah; as I mention in the next sentence
I do seem recall, though, that per the reports in the previous linked thread, 3.9 and I believe at least 3.10 was still buildable from source on Windows 7 (or with perhaps at most one small patch), as the reported issues were generally either with either the installer or with the built-against DLLs not being present by default on earlier Windows. Of course, that isnât the case foreverâŚ
Yup; at least as of a couple months ago, as of alpha 3+ CPython main
was still buildable from source with the full test suite passing on my old Windows 8.1 machine.
These are the cases the I can recall off the top of my head. Prior to 3.12, there are a couple of direct calls to PathCch*
functions, which require Windows 8+. There are a few more PathCch
calls if you count the new implementation of the py launcher in 3.11, but the old launcher implementation can be used instead.
Changes thus far in 3.12:
- The check for console pseudohandles in
set_inheritable()
in âPython/fileutils.câ was removed. This affectsos.set_inheritable()
,os.dup()
andos.dup2()
. - Dynamically linking of
AddDllDirectory()
andRemoveDllDirectory()
was removed. This affectsos.add_dll_directory()
andos.remove_dll_directory()
. - As mentioned,
os.getppid()
now uses the process snapshot API:PssCaptureSnapshot()
,PssQuerySnapshot()
,PssFreeSnapshot()
.
Itâs not critical, but we should have also remove the 32 KiB limit on console writes in _Py_write_impl()
in âPython/fileutils.câ. Itâs only relevant to the old console subsystem that was used prior to Windows 8. I forgot about this one in the last round of purging Windows 7 code. Itâs on the chopping block.
If you write a program in python 3.10 and use 3.10 features such as :=
and release it publicly, you have, in your words, âbannedâ users from using with with 3.9 or before, and have made yourself a vassal of the PSF Core developers.
Turn your question around. Why is Windows Python available for 8.1, released in 2013? Because we restrict ourselves to features available in the 2017 version of MS C and the 2013 version of Windows. An equivalent Python program would support 3.3. There are many on pypi.org that require something newer.