Faster large integer multiplication

Take a close look at flint (it does exactly what you describe):
https://www.flintlib.org/

Details are what sink grand schemes, and there’s no way to out-guess what they may turn out to be.

You never know. For example, in the old days GMP was rejected in many projects because its reaction to running out of memory was “kill the process”. That’s no good in the CPython context. CPython reacts to a failed memory allocation request by freeing all other temp memory allocated before then, putting everything in a “sane” state, and raising a MemoryError exception a program can catch.

>>> x = 1 << 1000000000000
Traceback (most recent call last):
...
MemoryError
>>> # And now I can continue as if nothing bad happened.

Does GMP still work that way? I don’t know. I know they changed things to allow using an external (to GMP) memory allocator, but I have no idea whether they went on to move Heaven and Earth (as CPython does) to support safe recovery from an allocation failure. That has to be forced to work - it doesn’t happen by magic.

Details matter a whole lot, and they’re often in areas that catch us by surprise.

As Oscar just mentioned in a different reply, a predictable one is sorting out GNU licenses. I’m not a lawyer, and we would have to pay one to get a semi-credible answer about what including LGPL-licensed code would imply for us.

Note that I’m not saying that anything of this sort kills the idea. I am saying that any number of surprises can pop up that would kill it. There’s just no way to know without putting major effort into getting most of the way to working code. Which I can pretty much guarantee will be more work than you’re expecting :wink:. CPython is not a new project and we can’t “break” anything anymore.

As I briefly hinted at before, while I wouldn’t oppose it, I’m not that keen on it either. Even if CPython did use mpz integers, I’d still install gmpy2, because it’s the many functions that supports that are the real value for me.

1 Like

Can you elaborate? I’d always seen it asserted that the PSFv2
license is GPL-compatible[*], and the LGPL is a good bit more
permissive than the GPL while also being GPL-compatible, so it would
seem like there’s no license conflict.

[*] citation not provided because this forum has proven to be
decidedly testy about marking anything with a hyperlink as spam

Again I am not an expert on these things but “compatible” does not seem like a good word to describe the situation. To me compatibility between A and B describes a symmetric situation where A is compatible with B and also B is compatible with A.

The situation with OSS licenses is more like type promotion rules: you can multiply an int and a float but the result will always be a float and definitely not an int. The Python license is compatible with GPL in the sense that you can take some GPL code and combine it with e.g. the CPython codebase but then the result will be GPL. The sense of license compatibility that you refer to is more like a lowest common denominator and it’s not workable for many users of Python.

Making Python GPL would be a complete deal breaker. LGPL might be different though but as Tim and I have both already said: we don’t know.

Don’t worry, this will never happen. In fact, it was considered and rejected decades ago. ObHistory: Python 1.6.1.

2 Likes

Current releases of the GMP libraries are dual-licensed, under GNU LGPL v3 and GNU GPL v2.

We, of course, would not use the GPL option, but the LGPL option. But I don’t know what bad effects LGPL could have. And, no, I don’t want to endure a thousand-msg thread disputing the differences between “static” and “dynamic” linking :wink:.

Which is another thing to consider: whenever we incorporate “foreign” code, we’re at the mercy of the distributor changing licenses if we want to keep up to date. For tabnanny.py, no problem - I can write a replacement while sleeping. But we don’t have the bandwidth to get anywhere close to recreating all the magic in the GMP libraries - they’re world-class state of the art (indeed, they define the state of the art) in a genuinely difficult domain.relatively few programmers know anything non-trivial about.

LOL! I had forgotten all about this bit:

Note: according to CNRI, Python 1.6.1 is GPL-compatible, but the FSF’s lawyer, has said that Python 1.6.1 is not compatible with the GPL. CNRI disagrees, and states the FSF’s lawyer has told CNRI’s lawyer that 1.6.1 is “not incompatible” with the GPL.

“Not incompatible - but not compatible either” still cracks me up :money_mouth_face:.

2 Likes