[Python] Why gmp is not in the standard library?

Licensing? IIRC, GMP is GPL.

Also, possibly, portability.

Cheers,
mwh

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
So is bsddb and that is included with python. Anyway, gmp is LGPL'd not
GPL'd.
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

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

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?


From http Thu Jan 15 21:26:33 2004
From: http (Paul Rubin)
Date: 15 Jan 2004 12:26:33 -0800
Subject: python & mathematical methods of picking numbers at random
References: <bu6ptu$kjm$1@solaris.cc.vt.edu>
Message-ID: <7xd69largm.fsf@ruckus.brouhaha.com>

Bart Nessux <bart_nessux at hotmail.com> writes:
Both are the same, as you can see by calculating the probability of
any given name being selected. What is the application, and the
computer environment? You may also need to worry about correlations
in the underlying Mersenne Twister PRNG. If the application is
something where randomness is very important (you're picking winners
for a big lottery or something) then you should use a better RNG.

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.

Yes.

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


John

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

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.

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

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.

Isn't some of this work done?

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

Brian

Tim Churches <tchur at optushome.com.au> wrote in message news:<mailman.418.1074201211.12720.python-list at python.org>...
However, if

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.