Hmm.  Looking back at my previous comments, I should explain my negativity a bit better.

1. Like Victor's issue 1814 work, this is great stuff, and very impressive.

2. I'm really not convinced that it belongs in the Python core.

To expand on 2: we already have a simple, highly portable, battle-tested implementation of big integers that's reasonably efficient for normal uses and requires little day-to-day maintenance.  We'd be replacing that with something that's a lot more complicated, less thoroughly tested, and *not* significantly more efficient in normal use-cases.  Apart from the pain of the transition (and any refactor of this size is bound to involve some pain), I'm particularly worried about future headaches involved in maintaining the external GMP dependency:  keeping up with bugfixes, managing the binary builds, etc.  I anticipate that that would add quite of a lot of work for the core team in general and those building releases in particular.  (And that's another reason that we should have a python-dev discussion, so that those involved in the release process get a chance to weigh in.)  To offset that, there needs to be a clear *benefit* to making this change.

A couple of specific questions for Hristo Venev:

- What's the current status of GMP on Windows?  IIUC, one of the motivations for the MPIR unfriendly fork of GMP was better Windows support.  Does your patch already build cleanly on Windows?

- Whom do you see this change benefiting?  Those doing serious large-number stuff on Python (SAGE users, for example) are presumably already using gmpy2 or something similar.

- Do you want to initiate the python-dev discussion, or leave that to someone else?

[I'm deliberately steering clear of the licensing issues; it needs discussion, but IANAL and I have nothing useful to contribute here.]