Prefer 64-bit CPython for Windows downloads

[segevfiner]

Is your feature request related to a problem? Please describe.
The download links for CPython for Windows (When browsing from Windows) link to the 32-bit version of Python. Considering that the Python launcher for Windows already prefers the 64-bit version (3.4.4.2. Customizing default Python versions), I would assume that the 64-bit version is preferred (I think 32-bit Windows is a rarity nowadays). Wouldn't it make sense to change it to the 64-bit version if the user is browsing from a 64-bit Windows?

The core developers for CPython on Windows should probably voice their opinion on this.

Describe the solution you'd like
The download links point to the 64-bit Python version.

Describe alternatives you've considered
It's also possible to link to both versions and let the user decide, with a link explaining the differences.

Additional context
For example, this link:

And there is another one on the download button hover in the top bar.

[Mariatta]

See also related Python-dev thread: https://mail.python.org/pipermail/python-dev/2018-July/154541.html
cc @python/windows-team

[zware]

My opinions: if we can reliably detect that the user is on 64-bit Windows, offer the 64-bit installer. If we can't do that reliably, offer links to both. If we can make a good guess, perhaps emphasize the one matching the platform we detected.

I definitely do not want to suddenly switch from unconditionally offering 32 to unconditionally offering 64.

[pfmoore]

I agree with @zware. The least-complex solution would be to just have two links, which I think is sufficient (and still a major improvement over just having the 32-bit installer). Being able to emphasise the "correct" one would be a bonus.

[berkerpeksag]

This is basically a duplicate of #171. See #1044 (comment) for my comment about using user agents to detect that the user is on 32-bit or 64-bit Windows.

[zooba]

I agree that just having both links is probably easiest and is sufficient.

I'd slightly prefer the 64-bit link to be less obvious (e.g. link text rather than a button), as the 32-bit version is going to work 100% of the time rather than 95% of the time, but I'm not hugely concerned.

[mwichmann]

Well, time has passed, and the discussion has continued in many places and here we still are. So let me take this place to list some points coming out of dealing with a not-empty stream of grumps sent to the webmaster email, several quite recently. These comments aren't anything new I imagine.

• 32 bit is the default without saying so; people assume we've detected the right version and offered it. Steve Dower still seems to feel strongly that 32-bit is the right default and he cites having access to metrics from the Windows ecosystem so I won't argue.
• to get to the others you have to follow some text which is, umm, not quite clear for this case: Looking for Python with a different OS? 64-bit Windows might be called a different OS than 32-bit but I doubt most people would think of it that way.
• alternatively, you can click on a release version, and then you have to scroll past release notes, which is trivial to do, but the first timer, in this age of "it better all be on one page" doesn't twig to the idea there's a list of downloads down at the end.
• On the release-version page, the Windows versions don't say 32-bit and 64-bit, which I believe is the way most people know to refer to them these days, instead they try to use processor designations, including using ones that haven't been used in years and years (EM64T - that was used just briefly in like 2004-6, thereabouts - I was working at Intel at the time and was involved with the project and we were bemused by the multitude of name changes before and after release)
• Nothing advises folks that there's nothing wrong with using the 32-bit Python on 64-bit windows so most are getting panicky for nothing.

Collectively we can improve this somehow, right?

[MaEtUgR]

We also ran into 32-Bit being the implicit (big download button) default on the Windows download page. People are complaining that the mavsdk module cannot be installed on the "default" 32-Bit python version mavlink/MAVSDK-Python#88. We don't currently support 32-Bit with new projects in 2019, we consider it deprecated.

Could the Website offer two big buttons one clearly labeled 32-Bit and one 64-Bit?

That would not make anything the first click default if there are ongoing discussions about which one should be.

[raionik]

I think the problem here is "32 bit is the default without saying so"
32 Bits Python has problems with some popular AI/ML related packages.
If you are not going to change this, at least you should state that you are downloading a 32 bit version of Python.

[mwichmann]

@zooba this topic rattles on and on, sorry... anything to add to this particular issue?

[zware]

It seems we have some consensus on just offering both links (perhaps with 64-bit slightly de-emphasized, but both clearly labeled); we just need someone to submit a PR. I have no idea how complex it's likely to be.

Agreed with @berkerpeksag that this is really a duplicate of #171.

[psifertex]

It's worth pointing out that Python 2 is finally being EOL'ed in January and yet Python 3 came out 2 years after Vista which was the start of Microsoft's default to x64 OS (though technically even earlier releases of windows had x64 support).

Given that, I'd argue that this is not a duplicate of #171 as I'd very much support the decision to move to 64-bit by default with the optional 32-bit install as an available option for the minority of users who need it.

For what it's worth, I checked out a number of apps that might be installed adjacent on someone's windows computer that installs Python. I considered: VSCode, Notepad++, Sublime Text, the go installer, java, vlc, chrome, and firefox. Several default to x64, but show both links. Some include 64bit by default and make 32-bit harder to find or not at all. Among those that default to 32-bit, only VLC doesn't explicitly state it was 32-bit and include an immediately visible 64-bit link (though it is available via a drop-down, so still an improvement over python.org).

I'll take a look at a potential PR based on @zware's comment above.

[negasora]

The installer linked to in the supernav for a given OS is determined by a "download_button" boolean field on the ReleaseFile model.

There is no "secondary download" boolean field (and imo it doesn't make sense to have one), so there's only one download option that can be displayed.

I'm not familiar with the method used for pushing new releases, but it seems like it'll just be ticking a different box on the latest release.

The other option is to add "32-bit" and "64-bit" boolean fields to ReleaseFile, and set download_button on the applicable 32-bit and 64-bit instances. I might make a PR for the latter, unless someone has a better idea.

[vsalvino]

I think the most common option is to look at the user-agent (can be done in client-side or server-side) and then show the 64-bit versus 32-bit link based on what the browser reports.

However my bigger problem with the downloads is that finding an alternate download is really difficult. It is very common that when setting up a new developer, they need Python 3.6 instead of 3.8 for example, or the 64-bit version, or something else to that effect.

So let's follow the journey that one might take to find the non-default option presented in the menu:

For any other version that is not the default in the menu, the visitor is taken to the downloads page.

The first thing on this page is a list of versions, with links to the PEP page about their releases. So thinking that I want Python 3.6, I end up clicking PEP 494 expecting a download.

Realizing that this PEP is way over my head, and not at all related to a download in any shape or fashion, I go back to the downloads page and scroll further. The "Looking for a specific release?" section is more helpful. However, the ordering is very confusing. They are sorted by date, not by release! Eventually I find Python 3.6.12 and click the download link.

But I am deceived! It is in fact not a download, but a link to another page. At the very bottom of the page is a list of files. OK - maybe this is finally going to be it?!

Alas, the files only contain the source code. There is no installer for any platforms! I carefully re-read the page above...

Security fix releases are produced periodically as needed and are source-only releases; binary installers are not provided.

* [ Internal screaming ] *

(Side note: is there any reason, through the magic of continuous integration that we have these days, to not provide binaries for security releases?)

Now to find some installable version of Python 3.6, I must repeat this whole process over and over again, until eventually landing on a page that provides an installer.

An hour later, I might be lucky to have installed Python. This assumes I am experienced, and haven't naively downloaded the source tarball and tried to figure out what the heck to do with it.

---

Anyhow, I realize this thread is probably not the place for this discussion... but I would like to propose a simple reorganization of the downloads page:

• Move "Active Python Releases" info section to the bottom. It is helpful info, but not the primary purpose of the "downloads" page.
• At the top of the page, add simple buttons/links (read: not a grid/table of links) to a page which organizes actual downloadable files, be it by Python minor release (3.6, 3.7, etc.) -OR- by platform (Windows, Mac, Linux).
• On these sub-download pages, a clear actually downloadable file should be available, not links to PEPs or links to more pages that only contain the source.

For all of it's warts, I think dotnet actually does this very well now: https://dotnet.microsoft.com/download. They provide a simple platform selector via a tab mechanism, a button to download the latest release, and a second button which links to a list of downloads for older releases.

Most other platforms, such as NodeJS or Go lang, provide a similar download experience.