As there are many existing (and free) C and C++ libraries that address these issues, it is expected that most of the work of the GMPY project will involve wrapping, and exposing to Python, exactly these existing libraries (possibly with additional "convenience" wrappers written in Python itself). For starters, we've focused on the popular (and excellent) GNU Multiple Precision library, GMP, exposing its functionality through module gmpy.
Existing Python modules expose a subset of the integral-MP (MPZ) functionality of earlier releases of the GMP library. The first GMPY goal is to develop this module into a complete exposure of MPZ, MPF (floating-point), and MPQ (rational) functionality of current GMP (release 3.1), that will fully support current Python (release 2.0) and its handy 'distutils' (and also support a "C API" allowing some level of interoperation with other C-written extension modules for Python).
Note: the module's ability to be used as a "drop-in replacement" for Python's own implementation of longs, to rebuild Python from sources in a version using GMP, was a characteristic of the gmp-module we started from, but is not a target of the gmpy project, and we have no plans to support it.
This first module is called gmpy, just like the whole project.
The extended MP floating-point facilities of MPFR will later also be considered for inclusion in gmpy (either within the same module, or as a further, separate add-on module).
Despite this, widespread feeling among Python cognoscenti appears to be against exposing such "mutable numbers". As a consequence, our current aim is for a first release of GMPY without mutability, to be followed at some later time by one which will also fully support in-place-mutable versions of number objects (as well as the default immutable ones), but only when explicitly and deliberately requested by a user (who can then be presumed to know what he/she is doing). Meanwhile, caching strategies are used to try to ameliorate performance issues, and appear to be somewhat worthwhile (so far, only MPZ objects are subject to this caching).
We've tended to solve other debatable design issues in a similar vein, i.e., by trying to work "like Python's built-in numbers" when there was a choice.
Release 0.2 had experimental support for in-place (mutating) operations for a few cases (+ - * for both kinds of numbers, / for mpf's only), but this was removed in recent releases (0.3 and later). (In exchange, 0.3 introduced caching tricks to offer substantial performance improvements for mpz's over 0.2, although not quite as much as might in some cases be obtained through mutability; 0.4 tweaked this a little bit more yet; 0.6 added caching for mpq's as well).
On most platforms, you will need to separately procure and install the GMP library itself to be able to build and use GMPY (note that 3.1.1 or better is needed; take care: some Linux releases come bundled with old GMP versions, such as GMP 2, and you may have to uninstall these and then install the latest GMP version!).
The exception to this need is under (32-bit) Windows, where binary-accompanied releases are the norm, and builds of GMP usable with MS VC++ 6 (the main C compiler used for Python on this platform) are traditionally hard to come by.
We started the GMPY project using a VC++ port of GMP.LIB "just found on the net", but have currently switched to the port by Jorgen Lundman found at ftp://ftp.whiterose.net/pub/lundman/ (bravo Lundy!). Windows users do not need to download from Jorgen's site: a separate 'binary library' package, including Lundy's ports of GMP.LIB and GMP.H, is made available on the gmpy project's ftp-space for Windows/VC++6 users that do want to re-build the gmpy module from sources; and also, another separate 'binary module' package is supplied, containing only the pre-built GMPY.PYD (note: this is a change from 0.4 and earlier releases, which bundled the two "binaries for windows" items into a single downloadable zipfile; this allows Win32 users to avoid downloading the largish library file if they don't need to rebuild from sources, and also has advantages for those who do want to rebuild, since the library is much more stable than GMPY.PYD itself).
Do note, however, that Win32 users should download the source-package as well, as currently that is the one including gmpy documentation and unit-tests!
A still-weakish point is with the output-formatting of mpf numbers; sometimes, this formatting ends up providing a few more digits than a given number's accuracy would actually warrant (a few noise digits after a long string of trailing '0' or '9' digits), particularly when the mpf number is built from a Python float -- the accuracy situation is quite a bit better when the mpf number is built from a string. Because of this, 0.6 has introduced an optional 'floating-conversion format string' module-level setting: if present, float->mpf conversion goes through an intermediate formatted string (by default, it still proceeds directly, at least for now); this does ameliorate things a bit, as does the better tracking done since 0.6 of the 'requested' precision for an mpf (as opposed to the precision actually 'assigned' to it); but the issue cannot yet be considered fully solved, and will probably need some design changes in the output formatting functionality.
The relative scarcity of unit-tests is another current issue to be solved, but at least we do know what we have to do about it. Specifically, starting with 0.3, we began supplying some gmpy unit-tests (for the mpz functionality, only) based on Tim Peters' doctest.py module (which is also included), and the tests were slightly extended in 0.4; in 0.5, unit-tests were added for the mpf, mpq, and random-number generation parts of the gmpy module; and 0.6 continued the trend by adding yet more tests. Still, the few hundreds of tests currently present are nowhere near enough, and the issue of verifying the actual coverage % which they provide has not been tackled yet. Specifically, Python will apparently have to be rebuilt from sources, with coverage-tracking enabled, to let us track coverage for the gmpy module's own C code.
Documentation at this stage will be kept up to date wrt the module, although sketchy (just a textfile -- GMP docs can meanwhile be used to take up the slack:-). Docstrings have also been added to each method and function that gmpy exposes 'for public consumption' (all of them, except for the '_copy' functions that exist only with an eye to future mutability).
The first alpha release, 1.0, is not deemed to be very far at this time. It will only differ in degree, not in kind, from the current pre-alphas. Main changes foreseen will include: re-architecting the module-level setting functions; exposing another little bit more of MPF and MPQ functionality; a more elegant form for this documentation; and, above all, more tests, timing-measurement scripts, examples. The current (somewhat optimistic) plans forecast all of this will happen on, or before, Dec 31, 2000.