Thanks for the updated patch!  Looks good, on a quick scan.

(One comment typo I noticed: there's a line
BASE - 3 = 2*MASK - 1
presumably this should be 2*BASE - 3 on the LHS.)

Just out of interest, is it possible to go further, and combine 4
partial multiplications at once instead of 2?  Or does the extra
bookkeeping involved make it not worth it?

I think it's important to make sure that any changes to longobject.c
don't slow down operations on small integers (where "small" means "less
than 2**32") noticeably.

Re: possible changes to PyLong_SHIFT

Yes, changing PyLong_SHIFT to 16 (or 32) would be complicated, and would
involve almost a complete rewrite of longobject.c, together with much
else...  It wasn't really a serious suggestion, but it probably would
provide a speedup.  The code in GMP gives some idea how things might work.

Changing PyLong_SHIFT to 30 doesn't seem like a totally ridiculous idea,
though.  One problem is that there's no 64-bit integer type (for
twodigits) in *standard* C89;  so since Python is only allowed to assume
C89 there would have to be some fallback code for those (very few,
surely) platforms that didn't have a 64-bit integer type available.

On 64-bit machines one could presumably go further, and have
PyLong_SHIFT be 60 (or 62, or 63 --- but those break the assumption
in long_pow that the PyLong_SHIFT is a multiple of 5).  This would
depend on the compiler providing a 128-bit type for twodigits (like
__uint128_t on gcc/x86-64).  Probably not worth it, especially if it
ends up slowing down operations on everyday small integers.

Any of these changes is also going to affect a good few other parts of
the codebase (e.g. marshal, pickle?, struct?, floatobject.c, ...).  It
shouldn't be difficult to find most of the files affected (just look to
see which files include longintrepr.h), but I have a suspicion there are
a couple of other places that just assume PyLong_SHIFT is 15).