BLD: remove support for 32 bit

[jreback]

seems microsoft has removed support starting 3.10 (as is numpy)

we should do the same

[thesamesam]

Apologies if I'm misunderstanding here, but it looks like Numpy isn't dropping 32-bit support entirely. It looks like they're only dropping wheel generation because of infra constraints but will continue to test.

I'm interested because in Gentoo, we still support a number of 32-bit architectures (arm, x86 being the two main ones), and Pandas ends up in the depgraph often unavoidably if we want to run test suites on programs.

Is the plan for Pandas to drop support entirely for 32-bit or to just stop producing wheels?

[jreback]

why should we support 32 bit at all?

this is just more work - sure it's probably easy but we are all volunteer

[mgorny]

Does being a volunteer justify removing work already done by (other) volunteers?

[jorisvandenbossche]

To be clear, @jreback only did a proposal to remove them, nothing has been decided yet, and your feedback on this idea is welcome.

Since numpy is not removing them, and if we also switch to cibuildwheel (cfr #44027, assuming this makes it easier to keep 32bit wheels), I personally think we can follow numpy on this.

[mgorny]

For the record, I don't have a problem with removing 32-bit wheels or 32-bit testing, if that is cumbersome. However, what I would like to avoid is removing the code to support 32-bit setups, or rejecting patches that fix them.

[jreback]

For the record, I don't have a problem with removing 32-bit wheels or 32-bit testing, if that is cumbersome. However, what I would like to avoid is removing the code to support 32-bit setups, or rejecting patches that fix them.

@mgorny these would always be welcome

it's the testing / support that can be cumbersome (it's not so burdensome more that if others are dropping support then we should as well; note that numpy is usually the last to drop support for things)

[jbrockmendel]

i agree with @jorisvandenbossche, following numpy's lead on this seems reasonable

xref https://discuss.python.org/t/dropping-32-bit-packages/5476

[lithomas1]

At the very least, I'd like to stop making 32-bit wheels by 2.0.
Note that this issue of dropping 32 bit has already come up before. xref #15889

[fangchenli]

+1

[lithomas1]

FYI, we are dropping Linux 32 bit builds after numpy 1.22 comes out, where they also will be dropping 32 bit Linux builds. Windows 32 bit will not be affected, and we will still test/support 32 bit.

[KOLANICH]

why should we support 32 bit at all?

this is just more work - sure it's probably easy but we are all volunteer

Pro tip: by not contributing into open source at all instead of contributing (and by not doing any other work you can avoid doing) you can keep even more work away of you.

[mattip]

I personally think we can follow numpy on this.

I proposed to drop 32-bit windows wheels in numpy/numpy#23717. I do not recall seeing 32-bit windows issues or requests over the past few years, has pandas? FWIW, SciPy already dropped 32-bit windows wheels.

[KOLANICH]

I am episodically using python on a Pentium III-based PC on Linux and until a very recent time I was also using a Core2Duo-based PC (clearly 64-bit capable, but it has only 2 GiB of RAM so I cannot afford wasting it on 64-bit pointers, also it has quite some other software installed, including some drivers for some expensive and legacy hardware that are 32-bit only. Now that PC is still used, including Python, but by other people (it is a company PC) ).

I do not recall seeing 32-bit windows issues or requests over the past few years

I guess it wouldn't have changed anything, users just have no power of vote in the matters involving the software they got free of charge (but, TBH, but to a lesser extent, in proprietary paid software too, but there - to lesser extent depending on how much unique and needed that software is). The decision to drop platforms is made by devs, not by users. If someone needs a platform devs are not willing to support, then he has to maintain an own fork (and undo the sabotage the devs of original will eventually do, and constantly fix the merge conflicts, and build the software himself (sometimes it is infeasible too) ) or find someone who is willing to do the required job and maybe pay him if he is unwilling to do it for free. Or just pay for new systems, if it is cheaper than to pay people for supporting old ones.

[lithomas1]

IMO, the only thing worth keeping 32-bit support for is WASM, at least until the memory64(https://github.com/WebAssembly/memory64) proposal goes through, as people seem interested in using pandas with pyodide.

I am episodically using python on a Pentium III-based PC on Linux and until a very recent time I was also using a Core2Duo-based PC (clearly 64-bit capable, but it has only 2 GiB of RAM so I cannot afford wasting it on 64-bit pointers, also it has quite some other software installed, including some drivers for some expensive and legacy hardware that are 32-bit only. Now that PC is still used, including Python, but by other people (it is a company PC) ).

Is there a reason that you are not OK using older versions of pandas?

[KOLANICH]

Is there a reason that you are not OK using older versions of pandas?

"Just use an old version" is a very poor argument. Of course I'm free to use old versions of everything (because a lot of things drop support with old versions of their dependencies, it is easy and pleasant to stop doing things you personally are not rewarded for, as Linus says, "good riddance", and as the Russian proverb says "[taking] a woman off a cart [makes it] easier for the horse"), but when one has to use old versions of everything because his machine cannot be used with new versions of everything, and something new requiring the new versions, that means that his machine is not a machine, but a piece of junk which proper place is on junkyard and not in a flat/home. When someone drops support of some hardware in something, he is essentially transforms someone's property into junk. I understand, there is ain't no such a thing as free lunch and it is unethical to demand people to do unpaid work. I just want everyone to always remember about that. There is a big difference between "something is broken just because our software is a complex system and noone IRL tests for it and noone has fixed that yet" and "something is broken because we have decided that in our software it will be broken, throw your calculator into junk and buy what we currently support", where dropping support is exactly this. Of course, only the latter option qualifies for "good riddance".

[jbrockmendel]

@KOLANICH i hope that rant was cathartic bc it was not a useful answer to the question

[KOLANICH]

You ask for simple answers, but our world is complex. The simple answer: right now I don't need bleeding edge version of Pandas on that machine. The complex answer:

1. I may need it in future
2. every drop of support creates chain reactions in multiple ways.
   a. forces users to replace their hardware, decreasing incentives to maintain support of older hardware for other software
   b. creates incentives for packages depending on the one that has dropped support to drop support. They are broken any fay for that hardware - why to waste resources on maintaining the redundant code then?

That's why I'm against of dropping support even in packages i don't use. Because dropping support in them makes closer the dropping in the packages I depend on.

[mgorny]

I'm a little confused here. Didn't we agree that general 32-bit support will be kept and patches will still be accepted? If that is the case, I'm not sure I don't understand what you are talking about now.

Gentoo very much needs 32-bit support in the latest version. Supporting old versions for a limited time usually triples the maintenance cost for us (and we're just a few volunteers maintaining hundreds of packages), and permanently is simply a no-go. Old versions tend to collect bugs (and Python is moving fast, so regressions aren't uncommon) and — more importantly — vulnerabilities. If we need to support the old version, it falls on us to fix all of them, and we simply can't afford to do that, let alone do it reliably when most of the projects are explicitly forcing us to install a newer version.

[mroeschke]

I think the decision here was that pandas no longer distributes wheels for 32 bit platforms (starting 2.1 IIRC) but pandas will continue to accept patches and test on 32 bit Linux so going to close