It happens to replace completely the other programming language and interpreter which share the same first letter.
* python-2.5-avr32-bin.tar.bz2: Python 2.5 binaries for AVR32
The below recipie is taken from http://www.ailis.de/~k/docs/crosscompiling/#python, and an updated configure script is from http://whatschrisdoing.com/blog/2006/10/06/howto-cross-compile-python-25/. I will supply proper Makefile targets and perhaps a proper autoconf-based system down the path 
# patch -p0 < Python2.5_xcompile.patch
# configure
# make python Parser/pgen
# mv python hostpython
# mv Parser/pgen Parser/hostpgen
# make distclean
Prepare for cross-compilation (update the host option for your os):
#CXX=avr32-linux-g++ \
CC=avr32-linux-gcc \
AR=avr32-linux-ar \
RANLIB=avr32-linux-ranlib \
./configure --host=i586-pc-linux-gnu --target=avr32-linux --prefix=$HOME/install
# make CXX=avr32-linux-g++ \
CC=avr32-linux-gcc \
AR=avr32-linux-ar \
RANLIB=avr32-linux-ranlib \
HOSTPYTHON=./hostpython \
HOSTPGEN=./Parser/hostpgen \
BLDSHARED="avr32-linux-gcc -shared"
# make install prefix=$HOME/install/usr \
HOSTPYTHON=./hostpython \
BLDSHARED="avr32-linux-gcc -shared" \
CROSS_COMPILE=yes
Using Christopher Lambacher's cross compile patch against Python 2.5 and passing the toolchain options to configure should allow Python to compile cleanly. I believe that the 'struct stat' and 'stropts.h' issues reported earlier were caused because the configure utility was run against the host libraries, which could have an incompatible timer header.
Type: # python
And start the fun life of developing python applications.