Why gmp is not in the standard library?

[Miki Tebeka]

Hello All,

Yes, you're right. Starting at 2**1000 I found three safe primes quite
quickly. Using my version I gave up waiting after seeing one safe prime
float by.

Which made me think why Python don't use gmp as it's primary math
package - we'll get fast results, a lot of number types and much more.

Can't think of any reason why Python is implementing its own long
numbers...
Can you enlighten me?

Thanks.
Miki

 

[Michael Hudson]

Hello All,



Which made me think why Python don't use gmp as it's primary math
package - we'll get fast results, a lot of number types and much more.

Can't think of any reason why Python is implementing its own long
numbers...
Can you enlighten me?

Licensing? IIRC, GMP is GPL.

Also, possibly, portability.

Cheers,
mwh

 

[Christopher A. Craig]

Which made me think why Python don't use gmp as it's primary math
package - we'll get fast results, a lot of number types and much more.

Can't think of any reason why Python is implementing its own long
numbers... Can you enlighten me?

Originally I'm sure licensing was a concern, but portability is still
a huge concern. I haven't tried to port gmp, but from what I've heard
it's an absolute nightmare. Python's long type, on the other hand,
was (before kmul) essentially a textbook (a Knuth text book, to be specific)
implementation of multiprecision integers. kmul takes a couple
shortcuts, especially in cases where the two numbers are of wildly
differing sizes, but is still pretty close to textbook. As such
longobject.c should compile pretty much anywhere with anything
resembling ANSI C with no problems.

 

[Skip Montanaro]

Miki> Which made me think why Python don't use gmp as it's primary math
Miki> package - we'll get fast results, a lot of number types and much
Miki> more.

Miki> Can't think of any reason why Python is implementing its own long
Miki> numbers... Can you enlighten me?

In addition to the reasons Michael Hudson provided, I'll add:

* Python's native longs have been around much longer than gmpy, perhaps
even predating gmp itself.

* Converting from Python's longs to gmpy would probably be at least a
moderately nontrivial undertaking.

Skip

 

[Brian Kelley]

This discussion partly happened a couple of years ago when mxNumber was
released from egenix. Here is a google link:

http://mail.python.org/pipermail/python-list/2001-April/040453.html

Licensing? IIRC, GMP is GPL.

So is bsddb and that is included with python. Anyway, gmp is LGPL'd not
GPL'd.

Also, possibly, portability.

GMP is incredibly portable, it does have one large flaw for use with python:

Q: I get a Segfault/Bus error in a program that uses GMP to calculate
numbers with several hundred thousand digits. Why?

A: GMP allocates most temporaries on the stack, and some machines give
user programs very little stack space by default. See setrlimit(2) for
information on how to increase the stack allocation. You can also change
it from the shell (using ulimit or limit depending on the shell). You
can also configure with --disable-alloca to instead allocate temporaries
using malloc, but that will make the library run somewhat slower.

Brian

 

[Skip Montanaro]

Brian> So is bsddb and that is included with python.

Bsddb is the name of Python's module which wraps Sleepycat's Berkeley DB,
commonly abbreviated as bdb. Bsddb is in Python and maintained by the
current developer (Greg Smith), so I assume any necessary accommodations
were made. A quick glance as a few of the Python files in the bsddb package
didn't make it look like GPL.

Bdb's license is not GPL:

http://www.sleepycat.com/download/oslicense.html

Skip

 

[Brian Kelley]

Bdb's license is not GPL:

http://www.sleepycat.com/download/oslicense.html

I stand corrected, it makes perfect sense that the Berkeley DB should be
released using the Berkeley license I don't know why I thought
otherwise.

That being said, wasn't there some issue with making the Python License
GPL compatible for issues like these?

 

[Tim Churches]

Which made me think why Python don't use gmp as it's primary math
package - we'll get fast results, a lot of number types and much more.

Can't think of any reason why Python is implementing its own long
numbers...
Can you enlighten me?

As others have said, re-engineering Python to use GMP numeric types
would be a huge undertaking. But I think there is a case to be made for
including gmpy as a library in the standard Python distribution. It is
very small and doesn't take long to compile, but is incredibly useful.

Of course, someone would need to prepare Python-style docs, and someone
would need to track GMP development and update the version included with
Python at each release (the current gmpy developers perhaps) - thus I
suspect it is more a resourcing issue than anything else. However, if
some dead wood is ever removed from the Python standard library, I would
love to see gmpy take its place. Thanks to the gmpy (and GMP) developer,
BTW.

--

Tim C

PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere
or at http://members.optushome.com.au/tchur/pubkey.asc
Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQBABwQjeJFGqer5k9ARAk6ZAKDYQxufa7bfyVp22g79Xeg3bEi8lgCdHMpQ
0g5XUJtyV9SRBPghFS3kQN0=
=C/Ft
-----END PGP SIGNATURE-----

 

[Jeremy Yallop]

I stand corrected, it makes perfect sense that the Berkeley DB should be
released using the Berkeley license I don't know why I thought
otherwise.

It's not the Berkeley licence, but it's not the GPL either, although
it's similar:

* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
[...]
* 3. Redistributions in any form must be accompanied by information on
* how to obtain complete source code for the DB software and any
* accompanying software that uses the DB software.

Note in particular "and any accompanying software". Previous versions
of BDB were under the Berkeley licence, which is still included below
the Sleepycat licence.

Jeremy.

 

[Brian Kelley]

Of course, someone would need to prepare Python-style docs, and someone
would need to track GMP development and update the version included with
Python at each release (the current gmpy developers perhaps) - thus I
suspect it is more a resourcing issue than anything else. However, if
some dead wood is ever removed from the Python standard library, I would
love to see gmpy take its place. Thanks to the gmpy (and GMP) developer,
BTW.

Isn't some of this work done?

http://www.lemburg.com/files/python/mxNumber.html

Brian

 

[John J. Lee]

I stand corrected, it makes perfect sense that the Berkeley DB should
be released using the Berkeley license I don't know why I thought
otherwise.

That being said, wasn't there some issue with making the Python
License GPL compatible for issues like these?

Yes.

"GPL-compatible" is very different from "GPL", of course.


John

 

[Terry Reedy]

"GPL-compatible" is very different from "GPL", of course.

I 'believe' that GPL-compatible means that someone can mix (compile) Python
with GPL code and release the mixture -- as a GPL bundle, which the PSF
does not want to do with Python itself but which repackagers are free to
do. It does not mean that PSF can put GPL code into the core and still
release Python with *its* non-GPL license.

tjr

 

[Rick Muller]

some dead wood is ever removed from the Python standard library, I would
love to see gmpy take its place. Thanks to the gmpy (and GMP) developer,

Amen to that. GMP is a sweet library, and gmpy makes it so easy to
play around with I can waste all sorts of time when I should be
getting real work done.