DEPS: drop 32-bit support

[jreback]

we barely test this. I don't seem much clamor for it in the real world.

[chris-b1]

I'm generally in favor, although a little messier on Windows. The default on https://www.python.org/downloads/ for Windows is still 32 bit (not sure why)

[gfyoung]

I agree with @chris-b1 on that sentiment regarding Windows. I would make sure that this is announced somewhat well in advance to make sure we don't surprise people.

[jreback]

@chris-b1 want to ping python and see why the downloads default like that?

[OmerJog]

There is no more default for windows.
When you choose a version you get all options (32, 64) and you choose from it.

[jreback]

Going to remove support for 32-bit starting in 0.25.0. Posting a doc warning in 0.24.0. If anyone has a really good reason why we should not do this, speak now or forever hold your peace.

32-bit support has a very small number of downloads now (@TomAugspurger will post some stats). We have very little testing (only on a daily build not accessible to regular contributors), and no testing whatsoever for windows. This is a burden.

[jorisvandenbossche]

Disclaimer: I am a complete noob with regard to this. But, just wondering: does this have implications for more "exotic" systems and platforms?
For example for ARM, Raspberry Pi and the like (cc @jjhelmus from berryconda) or WebAssembly (cc @rth in pyodide).

Further question: what are other packages doing? (numpy, scipy, matplotlib, sklearn, ...) Anybody aware of it already being dropped in one of those packages? (can't directly find a reference about it)

[jorisvandenbossche]

Quickly spoke with some colleagues: their feeling is that it is important to support ARM. Not necessarily 32 bit, but that might be the consequence (I don't know what version of ARM is most widely used, I understand the latest ARM also supports 64bit).

Also, it is maybe good to discuss where exactly the burden is: is it difficult to support in the actual code, or are it more the tests that are failing due to some reasons (int32 vs int64, precision, ..) without necessarily giving incorrect results? Are there ways to improve the situation around testing? Or is it the packaging? (but if that is the case, we can also drop binaries for it without dropping full support (like conda-forge did))

If it is mainly the testing that is the problem (tests easily break if we don't run tests on 32 bit regularly), we could also say that "we don't guarantee that the tests pass on 32 bit, but happily receive patches to get them passing" instead of "we don't support 32 bit".
In practice this might be more or less the same for us (we don't test / package for 32-bit), but it's a very different message to outside users / developers.