Comes from this thread on comp.lang.python:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/e15915df2e9cdd9/

The Makefile for distutils in the Mac binary for Python 3.1 specifies
the use of the OS X 10.4u SDK. However, XCode only includes the SDK for
the newest two versions of OS X, currently 10.5 and 10.6. This causes
build problems with gmpy on OS X Snow Leopard and the newest XCode. It
probably will also cause problems on other libraries that are compiled
using distutils but I've seen no other reports of issues. I don't know
enough about makefiles to come up with a patch that would work on all
supported versions of OS X. 

The offending code is line 118 in the Makefile, which installs itself in
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/config/Makefile.
The line is
UNIVERSALSDK=/Developer/SDKs/MacOSX10.4u.sdk

Here's a copy of Mensanator's errors:

$ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3
setup.py install
running install
running build
running build_ext
building 'gmpy' extension
creating build/temp.macosx-10.3-fat-3.1
creating build/temp.macosx-10.3-fat-3.1/src
Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/
MacOSX10.4u.sdk
Please check your Xcode installation
gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -
fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I./src -I/
opt/local/include -I/Library/Frameworks/Python.framework/Versions/3.1/
include/python3.1 -c src/gmpy.c -o build/temp.macosx-10.3-fat-3.1/src/
gmpy.o
In file included from src/gmpy.c:206:
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:11:20: error: limits.h: No such file or directory
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:14:2: error: #error "Something's broken.  UCHAR_MAX should be
defined in limits.h."
/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1/
Python.h:18:

This is happening because "./configure --enable-universalsdk" was used
in MacPorts.

In Python source, "/Mac/BuildScript/build-installer.py" can be used to
drive ./configure with another SDK (via --sdk-path) so maybe macports
itself should use it as a pre-built step.

In any case, maybe such an option could be added in configure itself. I
am adding Ronald into the loop, he'll propably know what's the best
thing to do.

AFAIK This is already fixed in the repository. 

I don't have time to verify this right now, but will do so later this week 
(which is why I'm assigning the issue to myself)

I forgot to mention the workaround for the 3.1 release: reinstall XCode 
and make sure that you don't do the default install, but select the 10.4u 
SDK for installation as well.

You may then run into linking issues, they only workaround for that is to 
patch the makefile: use 'gcc-4.0' instead of just 'gcc' for compiling and 
linking.

The issue here isn't with Macports (which doesn't do a universal build
by default). It's with the installer on python.org which is also a
universal binary.

Macports has the advantage of knowing which OS version it's being
compiled on so it should just require a patch to the portfile. If this
issue does show up on the Macports universal build, someone should file
another report with them.

I've fixed this issue in the repository earlier today, the installer for the next 3.1 release will include that fix.

Doesn't breaking installation of packages on a major platform warrant a quicker release of a fix?

> Doesn't breaking installation of packages on a major platform warrant a quicker release of a fix?

No, only security-related issues may warrant a change to the release
schedule.