[Gregory P. Smith <greg@krypto.org>]

The reason for digits being a multiple of 5 bits should be revisited vs its original intent

I added that. The only intent was to make it easier to implement bigint exponentiation easily while viewing the exponent as being in base 32 (so as to chew up 5 bits at a time).. Since the number of digit bits _was_ 15 at the time, and it was 'obvious enough" that 30 bits would work fine when 64-bit boxes became important enough to care about, it was easy to settle on "multiple of 5" as a quick, pragmatic tradeoff. The number controls how much space and time is needed to precompute a lookup table for a "large" (many bits) power - and powers can be very large indeed in the modular exponentiation case. I doubt Python will move beyond 30-bit digits. While 64-bit support became increasingly and steadily more widespread (both SW and HW) in the 32-bit world. I see very much less enthusiasm to move beyond 64 bits. Yes, 64x64 -> 128 multiply is spreading, but that's about it. Some applications can make very good use of that, but, in the grand scheme of things, they remain niche. Whole universes of apps are getting real benefit by moving from 32 to 64 bits. That's needed just to get integers big enough to represent physical memory addresses in many consumer desktops now. But we'll likely never need to go beyond 64 bits for that. In any case, "multiple of 5" is a shallow constraint. and getting rid of it shouldn't require more than rewriting longobject.c's long_pow()'s for (j = PyLong_SHIFT - 5; j >= 0; j -= 5) { loop in a more convoluted way to cross digit boundaries when trying to suck up "the next" 5 bits. In fact, there are good reasons to make that loop more convoluted anyway, but I never got around to it (it "should" instead be aiming to find "the next" 5-bit slice that ends with a 1-bit, which would allow cutting the aforementioned precomputed table in half).