Commit fe996b48 authored by Martin Kelly's avatar Martin Kelly

Import Upstream version 1.17

parent 2517339f
Metadata-Version: 1.0
Name: gmpy
Version: 1.17
Summary: MPIR/GMP interface to Python 2.4+ and 3.x
Author: Case Van Horsen
License: UNKNOWN
Description: UNKNOWN
Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Intended Audience :: Developers
Classifier: Intended Audience :: Science/Research
Classifier: License :: OSI Approved :: GNU Library or Lesser General Public License (LGPL)
Classifier: Natural Language :: English
Classifier: Operating System :: MacOS :: MacOS X
Classifier: Operating System :: Microsoft :: Windows
Classifier: Operating System :: POSIX
Classifier: Programming Language :: C
Classifier: Programming Language :: Python :: 2
Classifier: Programming Language :: Python :: 3
Classifier: Topic :: Scientific/Engineering :: Mathematics
Classifier: Topic :: Software Development :: Libraries :: Python Modules
General MultiPrecision arithmetic for Python -- i.e., Python 2.4+ and 3.0+
interface module for library GMP 4 -- release 1.10 (July 2009).
Note: There is a bug in GMP 4.2.3 that causes a segmentation fault when
running There are patches available at the GMP website or use
GMP 4.2.4.
The gmpy project has moved (since quite a while ago!-) to Google Code:
Please check that site for better-updated sources, docs, etc.
Detailed documentation is in subdirectory doc.
To install gmpy 1.10 from sources (you need to have Python 2.4 or better, and
GMP 4 or MPIR, previously installed): at a shell prompt, python install
Beginning with gmpy 1.10, MPIR is supported as an alternative library to GMP.
To install gmpy 1.10 with MPIR support, use the following command:
python build_ext -DMPIR install
Note that, on Windows, you may use the distributed binary release, rather
than having to rebuild from source. To build GMP and GMPY from source, see the
file "windows_build.txt".
Binary installations are also available for MacOSX (and for many Linux
distributions, but those are not distributed by the gmpy project).
To test your installation: cd test, then python
For any support request, mail Alex Martelli, (or, better, use
the issues and wiki entries of the Google Code URL previously given).
Changes in gmpy 1.10
Number conversion rules have changed.
The arguments in operations involving mixed types are converted using the
following rules:
Integer --> Rational --> Floating-point
'int' 'Fraction' 'float'
'long' 'mpq' 'Decimal'
'mpz' 'mpf'
Old behavior:
mpz(1) + float(1.2) --> float(2.2)
mpz(1) + Decimal('1.2') --> mpz(2)
New behavior:
mpz(1) + float(1.2) --> mpf(2.2)
mpz(1) + Decimal('1.2') --> mpf(2.2)
As a side-effect of Python 3.x compatibility, coerce() is no longer supported.
The result of // will be an mpz if the arguments are Integer or Rational, but
will be an mpf if either argument is Floating-point.
The result of 'mpq'/'mpq' will be an 'mpq'. It will not be converted to an
'mpf'. This matches the behavior of the 'Fraction' type in Python 3.x.
The result of 'mpz'/'float' will an 'mpf' instead of a 'float'.
Type-specific methods require appropriate arguments.
If you call an 'mpq' specific method, i.e. gmpy.qdiv, the arguments are
required to be either integer or rational. Floating-point arguments are not
automatically converted to rational when an 'mpq' specific method is
called. Similarly, if you call an 'mpz' specific method, the arguments must
be integers.
Other bug fixes and changes
Corrected formating bug with mpf where last digit was missing.
The wording of some error messages has changed. The type of error has not
The result of gcdext may no longer be the "minimal" values. They result
does solve gcd(a,b) = ax + by. This is a side-effect of GMP 4.3 using a
different (faster) algorithm.
Unicode strings are now supported.
This diff is collapsed.
<TITLE>Welcome to General Multiprecision PYthon
<LINK rel="stylesheet"
body { margin-left: 30; margin-right: 30; }
Last updated on: 2008, June 22;
for GMPY release: 1.04
<A href="">
<IMG src=""
width="88" height="31" border="0" alt="Go to Google Code gmpy page"></A>
<H1>GMPY Project goals and strategies</H1>
The General Multiprecision PYthon project (GMPY) focuses on
Python-usable modules providing multiprecision arithmetic
functionality to Python programmers. The project mission
includes both C and C++ Python-modules (for speed) and pure
Python modules (for flexibility and convenience); it
potentially includes integral, rational and floating-point
arithmetic in any base. Only cross-platform functionality
is of interest, at least for now.
As there are many good existing 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,
<A HREF="">GMP</A>,
exposing its functionality through module <b>gmpy</b>.
<H1>The GMPY Module</H1>
Python modules older than GMPY exposes a subset of the integral-MP
(MPZ) functionality of earlier releases of the GMP library. The
first GMPY goal (currently nearly reached) was to develop the gmpy
module into a complete exposure of MPZ, MPF (floating-point), and
MPQ (rational) functionality of current GMP (release 4), as well
as auxiliary functionality such as random number generation, with
full support for current Python releases (2.3 and up) and the
Python 'distutils' (and also support for a "C API" allowing some
level of interoperation with other C-written extension modules for
<b>Note</b>: the module's ability to be used as a "drop-in
replacement" for Python's own implementation of <i>long</i>s,
to rebuild Python from sources in a version using GMP, was a
characteristic of the gmp-module we started from, but is
<b>not</b> a target of the gmpy project, and we have no plans
to support it.
This first GMPY
module is called <b>gmpy</b>, just like the whole project.
The extended MP floating-point facilities of
will later also be considered for inclusion in gmpy (either within
the same module, or as a further, separate add-on module).
[[ Rooting for MPFR to be merged with GMP so we can avoid some
awkwardness (but seeing no movement on this front so far) ]].
<H2>Mutability... but <u>not</u> for now</H2>
Early tests have shown that supporting Python 2's "in-place
operation" functionality (by making MPZ, MPF and MPQ Python objects
<b>mutable</b>) would offer a substantial performance boost.
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 or she is doing). Meanwhile, caching strategies are used
to ameliorate performance issues, and appear to be reasonably
worthwhile (so far, only MPZ and MPQ objects are subject to this
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 and two or more alternatives made sense.
<H1>Project Status and near-future plans</H1>
The gmpy module's current release (latest current release
as of 2008/10/16: 1.04) is available for download in both
source and Windows-binary form, and Mac-binary form too.
gmpy 1.04 exposes all of the mpz, mpq
and mpf functionality that was already available in GMP 3.1, and
most of the random-number generation functionality (there are no
current plans to extend gmpy to expose other such functionality,
although the currently experimental way in which it is architected
is subject to possible future changes).
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
4.0.1 or better is needed; take care: some Linux releases come bundled
with <strong>older</strong> GMP versions, such as GMP 3, and you may
have to install the latest GMP version instead -- beware also of
/usr/lib vs /usr/local/lib issues.
Please read the file "windows_build.txt" for detailed instructions on
compiling GMP and GMPY using the freely available MinGW tools.
[[ OLD: 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", and later a port by Jorgen Lundman, but are currently relying
on other volunteers to build Windows binaries since we don't have any
Windows machine any more. <a
href="">This site</a> does appear
to offer all needed files and instructions for Windows developers who
want to re-build the gmpy module from sources; the gmpy project itself
just supplies a separate 'binary module' package is supplied, containing
only the pre-built GMPY.PYD, for those who do <b>not</b> want to
re-build from sources. ]]
<b>Do</b> note, however, that <b>all</b> gmpy users should download the
gmpy source-package as well, as currently that is the one including
<b>gmpy</b> documentation and unit-tests!
<H2>Currently-open issues</h2>
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 <b>string</b>.
Because of this, since release 0.6, gmpy introduced an optional
'floating-conversion format string' module-level setting: if present,
float-&gt;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, with further enhancements in 0.7) of the 'requested'
precision for an mpf (as opposed to the precision the underlying GMP
actually 'assigns' to it); but the issue cannot yet be considered fully
solved, and may well still need some design changes in the output
formatting functionality.
Unit tests are not considered a weak point any more; the over 1000
unit-tests now being run provide a decent cover of 93+% SLOC for gmpy.c,
up from 72% in 0.7. The non-covered SLOCs (about 150 of gmpy.c's
current 2311 executable lines out of 6205 total)
are mostly disaster-tests to handle out-of-memory
situations, a smattering of 'defensive
programming' cases (to handle situations that 'should never happen,
but'...) and some cases of the new experimental 'callbacks' facility
(mostly provided for the specific use of PySymbolic, and intended to be
tested by that package). We'll have to do better, eventually (presumably with
some mocking approach e.g. to simulate out-of-memory situations), but, for now,
this can be considered OK.
In the attempt to make gmpy as useful as can be for both stand-alone
use, and also in the context of PySymbolic, a tad too many design
decisions have been delayed/postponed by introducing module-level
flags, letting us 'have it both ways' in the current
gmpy 1.04; this has produced a somewhat unwieldy mix of module-level
flag-setting and call-back functions. This whole area's architecture
will neet to be revisited, including other such design-decisions yet.
<H2>Near-future plans</h2>
Future releases may have changes including: re-architecting the
module-level setting functions; more elegantly formatted documentation;
more timing-measurement scripts and usage-examples. Some of the
currently experimental 'callbacks' will also be removed, having been
proven unnecessary. All relevant GMP 4 functionality will be exposed.
No predictions on timing, though. gmpy 1.04 meets all current needs
of the main author, so his motivation to work more on it is low:-).
So, don't hold your breath (pitching in and helping it happen, on the
other hand, _might_ be advisable, and will surely yield results:-).
<A HREF="">Project page on</A>
<A href="">
<IMG src=""
width="88" height="31" border="0" alt="Go to Google Code gmpy page"></A>
This diff is collapsed.
News update as of gmpy 1.04: macports AKA darwinports now comes with GMP 4.2.4
and thus offers again the simplest and most effective preliminary to building
and installing gmpy (I've tried Pyton 2.5.* and 2.6.* on OSX 10.5 with Intel
processors, and 2.5.1 on OSX 10.5 with PowerPC processors -- sorry but I don't
currently have at hand other Python/OS/processor combinations to try!).
How to build gmpy with XCode 3 and Mac OS X 10.5 (one easy way):
- install macports AKA darwinports, see
(you do need to install XCode 3 first); no need to set PATH &c
or install X11 etc etc, if all you need is to build gmpy
- instructions at are wrong, just do (after install
& selfupdate of darwinports): sudo /opt/local/bin/port install gmp
(or if you have an older macports gmp, port update it)
- now, 'python install' in gmpy's directory should work just fine
- verify with python test/ -- expect at the end of the output:
1214 passed and 0 failed.
Test passed.
For older systems, or to try and do without XCode, see:
and good luck!
There have been multiple requests to support efficient inplace operations
on mutable integers. gmpy 1.10 did not provide any extra support for inplace
operations. gmpy 1.11 adds support for the standard, immutable versions of
the inplace operations. There is a compile-time option (-DMUTATE) that uses
mutating versions of the inplace operations. A simple benchmark is:
(Python 2.6)
fact = gmpy.mpz(1)
for i in xrange(10000000):
fact *= i
(Python 3.1)
fact = gmpy.mpz(1)
for i in range(10000000):
fact *= i
Measured results:
gmpy ver: | 1.10 | 1.11(immutable) | 1.11 (mutable)
Python 2.6 | 2.482s | 2.380s (4%) | 1.712s (31%)
Python 3.1 | 2.470s | 2.374s (4%) | 1.846s (25%)
The question is "How much benefit is there in real-world code?" If you have
examples of real-world code that see a significant improvement with mutable
integers, please let us know at:
Build instructions
To build gmpy with mutable integers, use the following command:
$python build_ext -DMUTATE -f install
If you are using MPIR instead of GMP, use the following command:
$python build_ext -DMPIR,MUTATE -f install
Hashing is disabled for mpz when built with MUTATE enabled.
The behavior of many expressions involving mpz will change.
To make a copy of an mpz, use "x=a._copy()".
# pysymbolicext is no longer supported. It is included soley to test the
# exported C API.
import sys
from distutils.core import setup, Extension
if sys.version.find('MSC')==-1:
gmpy_ext = Extension('pysymbolicext', sources=['src/pysymbolicext.c'],
gmpy_ext = Extension('pysymbolicext', sources=['src/pysymbolicext.c'],
setup (name = "pysymbolicext",
version = "0.2",
description = "PySymbolic Python/GMP extensions (Pollard's rho)",
author = "Pearu Peterson",
maintainer = "Alex Martelli",
maintainer_email = "",
url = "",
ext_modules = [ gmpy_ext ]
import sys, os
from distutils.core import setup, Extension
# monkey-patch distutils if it can't cope with the "classifiers" and
# "download_url" keywords
if sys.version < '2.2.3':
from distutils.dist import DistributionMetadata
DistributionMetadata.classifiers = None
DistributionMetadata.download_url = None
# Check if MPIR or GMP should be used.
for token in sys.argv:
if token.startswith('-D') and 'MPIR' in token:
# determine include and library dirs
incdirs = libdirs = ()
if sys.version.find('MSC') == -1:
# Unix-like build (including MacOSX)
incdirs = ['./src']
dirord = ['/usr', '/opt/local', '/usr/local']
for adir in dirord:
lookin = '%s/include' % adir
if os.path.isfile(lookin + '/' + mplib + '.h'):
dirord = [adir]
for adir in dirord:
lookin = '%s/lib' % adir
if os.path.isfile(lookin + '/lib' + mplib + '.a'):
libdirs = [lookin]
# decomment next line (w/gcc, only!) to support gcov
# os.environ['CFLAGS'] = '-fprofile-arcs -ftest-coverage -O0'
# prepare the extension for building
gmpy_ext = Extension('gmpy', sources=['src/gmpy.c'],
setup (name = "gmpy",
version = "1.17",
maintainer = "Case Van Horsen",
maintainer_email = "",
url = "",
description = "MPIR/GMP interface to Python 2.4+ and 3.x",
classifiers = [
'Development Status :: 5 - Production/Stable',
'Intended Audience :: Developers',
'Intended Audience :: Science/Research',
'License :: OSI Approved :: GNU Library or Lesser General Public License (LGPL)',
'Natural Language :: English',
'Operating System :: MacOS :: MacOS X',
'Operating System :: Microsoft :: Windows',
'Operating System :: POSIX',
'Programming Language :: C',
'Programming Language :: Python :: 2',
'Programming Language :: Python :: 3',
'Topic :: Scientific/Engineering :: Mathematics',
'Topic :: Software Development :: Libraries :: Python Modules',
ext_modules = [ gmpy_ext ]
This diff is collapsed.
gmpy C API extension header file.
Part of Python's gmpy module since version 0.4
Created by Pearu Peterson <>, November 2000.
Edited by A. Martelli <>, December 2000.
Version 1.02, February 2007.
Version 1.03, June 2008
Version 1.04, June 2008 (no changes)
Version 1.05, February 2009 (support MPIR)
#ifdef __cplusplus
extern "C" {
#if defined(MS_WIN32) && defined(_MSC_VER)
/* the __MPN determination in stock gmp.h doesn't work, so...: */
# define __MPN(x) __gmpn_##x
# define _PROTO(x) x
#define inline __inline
#if defined MPIR
#include "mpir.h"
#include "gmp.h"
/* ensure 2.5 compatibility */
#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
#define PY_FORMAT_SIZE_T ""
#if PY_VERSION_HEX < 0x030200A3
typedef long Py_hash_t;
typedef unsigned long Py_uhash_t;
/* Header file for gmpy */
typedef struct {
/* PyObject* callable; */
/* long flags; */
} mpob;
typedef struct {
mpob ob;
mpz_t z;
} PympzObject;
typedef struct {
mpob ob;
mpq_t q;
} PympqObject;
typedef struct {
mpob ob;
mpf_t f;
size_t rebits;
} PympfObject;
/* #define MPOBCAL(obj) ((mpob*)obj)->callable */
/* #define MPOBFLA(obj) ((mpob*)obj)->flags */
#define Pympz_AS_MPZ(obj) (((PympzObject *)(obj))->z)
#define Pympq_AS_MPQ(obj) (((PympqObject *)(obj))->q)
#define Pympf_AS_MPF(obj) (((PympfObject *)(obj))->f)
#define Pympz_Type_NUM 0
#define Pympq_Type_NUM 1
#define Pympf_Type_NUM 2
/* C API functions */
#define Pympz_new_NUM 3
#define Pympz_new_RETURN PympzObject *
#define Pympz_new_PROTO (void)
#define Pympq_new_NUM 4
#define Pympq_new_RETURN PympqObject *
#define Pympq_new_PROTO (void)
#define Pympf_new_NUM 5
#define Pympf_new_RETURN PympfObject *
#define Pympf_new_PROTO (size_t bits)
#define Pympz_dealloc_NUM 6
#define Pympz_dealloc_RETURN void
#define Pympz_dealloc_PROTO (PympzObject *self)
#define Pympq_dealloc_NUM 7
#define Pympq_dealloc_RETURN void
#define Pympq_dealloc_PROTO (PympqObject *self)
#define Pympf_dealloc_NUM 8
#define Pympf_dealloc_RETURN void
#define Pympf_dealloc_PROTO (PympfObject *self)
#define Pympz_convert_arg_NUM 9
#define Pympz_convert_arg_RETURN int
#define Pympz_convert_arg_PROTO (PyObject *arg, PyObject **ptr)
#define Pympq_convert_arg_NUM 10
#define Pympq_convert_arg_RETURN int
#define Pympq_convert_arg_PROTO (PyObject *arg, PyObject **ptr)
#define Pympf_convert_arg_NUM 11
#define Pympf_convert_arg_RETURN int
#define Pympf_convert_arg_PROTO (PyObject *arg, PyObject **ptr)
/* Total number of C API pointers */
#define Pygmpy_API_pointers 12
/* This section is used when compiling gmpy.c */
static PyTypeObject Pympz_Type;
#define Pympz_Check(v) (((PyObject*)v)->ob_type == &Pympz_Type)
static PyTypeObject Pympq_Type;
#define Pympq_Check(v) (((PyObject*)v)->ob_type == &Pympq_Type)
static PyTypeObject Pympf_Type;
#define Pympf_Check(v) (((PyObject*)v)->ob_type == &Pympf_Type)
static Pympz_new_RETURN Pympz_new Pympz_new_PROTO;
static Pympz_dealloc_RETURN Pympz_dealloc Pympz_dealloc_PROTO;
static Pympz_convert_arg_RETURN Pympz_convert_arg Pympz_convert_arg_PROTO;
static Pympq_new_RETURN Pympq_new Pympq_new_PROTO;
static Pympq_dealloc_RETURN Pympq_dealloc Pympq_dealloc_PROTO;
static Pympq_convert_arg_RETURN Pympq_convert_arg Pympq_convert_arg_PROTO;
static Pympf_new_RETURN Pympf_new Pympf_new_PROTO;
static Pympf_dealloc_RETURN Pympf_dealloc Pympf_dealloc_PROTO;
static Pympf_convert_arg_RETURN Pympf_convert_arg Pympf_convert_arg_PROTO;
#define export_gmpy(m) { \
PyObject *d; \
static void *Pygmpy_API[Pygmpy_API_pointers]; \
PyObject *c_api_object; \
Pygmpy_API[Pympz_Type_NUM] = (void*)&Pympz_Type;\
Pygmpy_API[Pympq_Type_NUM] = (void*)&Pympq_Type;\
Pygmpy_API[Pympf_Type_NUM] = (void*)&Pympf_Type;\
Pygmpy_API[Pympz_new_NUM] = (void*)Pympz_new;\
Pygmpy_API[Pympz_dealloc_NUM] = (void*)Pympz_dealloc;\
Pygmpy_API[Pympz_convert_arg_NUM] = (void*)Pympz_convert_arg;\
Pygmpy_API[Pympq_new_NUM] = (void*)Pympq_new;\
Pygmpy_API[Pympq_dealloc_NUM] = (void*)Pympq_dealloc;\
Pygmpy_API[Pympq_convert_arg_NUM] = (void*)Pympq_convert_arg;\
Pygmpy_API[Pympf_new_NUM] = (void*)Pympf_new;\
Pygmpy_API[Pympf_dealloc_NUM] = (void*)Pympf_dealloc;\
Pygmpy_API[Pympf_convert_arg_NUM] = (void*)Pympf_convert_arg;\
c_api_object = PyCObject_FromVoidPtr((void*)Pygmpy_API, NULL);\
d = PyModule_GetDict(m);\
PyDict_SetItemString(d, "_C_API", c_api_object);\
/* This section is used in other C-coded modules that use gmpy's API */
static void **Pygmpy_API;
#define Pympz_Check(op) \
((op)->ob_type == (PyTypeObject *)Pygmpy_API[Pympz_Type_NUM])
#define Pympz_Type (*(PyTypeObject *)Pygmpy_API[Pympz_Type_NUM])
#define Pympq_Check(op) \
((op)->ob_type == (PyTypeObject *)Pygmpy_API[Pympq_Type_NUM])
#define Pympq_Type (*(PyTypeObject *)Pygmpy_API[Pympq_Type_NUM])
#define Pympf_Check(op) \
((op)->ob_type == (PyTypeObject *)Pygmpy_API[Pympf_Type_NUM])
#define Pympf_Type (*(PyTypeObject *)Pygmpy_API[Pympf_Type_NUM])
#define Pympz_new \
(*(Pympz_new_RETURN (*)Pympz_new_PROTO) Pygmpy_API[Pympz_new_NUM])
#define Pympz_dealloc \
(*(Pympz_dealloc_RETURN (*)Pympz_dealloc_PROTO) Pygmpy_API[Pympz_dealloc_NUM])
#define Pympz_convert_arg \
(*(Pympz_convert_arg_RETURN (*)Pympz_convert_arg_PROTO) Pygmpy_API[Pympz_convert_arg_NUM])
#define Pympq_new \
(*(Pympq_new_RETURN (*)Pympq_new_PROTO) Pygmpy_API[Pympq_new_NUM])
#define Pympq_dealloc \
(*(Pympq_dealloc_RETURN (*)Pympq_dealloc_PROTO) Pygmpy_API[Pympq_dealloc_NUM])
#define Pympq_convert_arg \
(*(Pympq_convert_arg_RETURN (*)Pympq_convert_arg_PROTO) Pygmpy_API[Pympq_convert_arg_NUM])
#define Pympf_new \
(*(Pympf_new_RETURN (*)Pympf_new_PROTO) Pygmpy_API[Pympf_new_NUM])
#define Pympf_dealloc \
(*(Pympf_dealloc_RETURN (*)Pympf_dealloc_PROTO) Pygmpy_API[Pympf_dealloc_NUM])
#define Pympf_convert_arg \
(*(Pympf_convert_arg_RETURN (*)Pympf_convert_arg_PROTO) Pygmpy_API[Pympf_convert_arg_NUM])
#define import_gmpy() \
{ \
PyObject *module = PyImport_ImportModule("gmpy");\
if (module != NULL) { \
PyObject *module_dict = PyModule_GetDict(module); \
PyObject *c_api_object = PyDict_GetItemString(module_dict, "_C_API"); \
if (PyCObject_Check(c_api_object)) { \
Pygmpy_API = (void **)PyCObject_AsVoidPtr(c_api_object); \
} \
} \
static int
Pygmpy_API = (void **)PyCapsule_Import("gmpy._C_API", 0);
return (Pygmpy_API != NULL) ? 0 : -1;
#ifdef __cplusplus
#endif /* !defined(Py_GMPYMODULE_H */

Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "gmpy", "gmpy.vcproj", "{CA80B30F-7C98-4A7C-A412-9E0012C5E27E}"
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|Win32 = Debug|Win32
Debug|x64 = Debug|x64
Release|Win32 = Release|Win32
Release|x64 = Release|x64
GlobalSection(ProjectConfigurationPlatforms) = postSolution
{CA80B30F-7C98-4A7C-A412-9E0012C5E27E}.Debug|Win32.ActiveCfg = Debug|Win32
{CA80B30F-7C98-4A7C-A412-9E0012C5E27E}.Debug|Win32.Build.0 = Debug|Win32
{CA80B30F-7C98-4A7C-A412-9E0012C5E27E}.Debug|x64.ActiveCfg = Debug|x64
{CA80B30F-7C98-4A7C-A412-9E0012C5E27E}.Debug|x64.Build.0 = Debug|x64
{CA80B30F-7C98-4A7C-A412-9E0012C5E27E}.Release|Win32.ActiveCfg = Release|Win32
{CA80B30F-7C98-4A7C-A412-9E0012C5E27E}.Release|Win32.Build.0 = Release|Win32
{CA80B30F-7C98-4A7C-A412-9E0012C5E27E}.Release|x64.ActiveCfg = Release|x64
{CA80B30F-7C98-4A7C-A412-9E0012C5E27E}.Release|x64.Build.0 = Release|x64
GlobalSection(SolutionProperties) = preSolution
HideSolutionNode = FALSE
<?xml version="1.0" encoding="Windows-1252"?>
ProjectType="Visual C++"