There are currently 73 files with hard-coded references to /usr/local,

To see what I'm talking about, unpack a source Python tarball, and check it out like so:

# cd Python-2.7.3
# grep -Rl '\/usr\/local' ./* | wc -l
73

To read more detail,
# grep -R '\/usr\/local' ./*


Some of these hardcoded /usr/local lines are innocuous or merely misleading,

./README:        1) CONFIG_SHELL=/usr/local/bin/bash CC=cc RANLIB=: \
- or -
./Demo/tkinter/guido/ManPage.py:    MANDIR = '/usr/local/man/mann'

Yet, some of these create unexpected installation behavior when configuring using the --prefix flag to specify an alternative install location, 

./setup.py:        # Ensure that /usr/local is always used
- or-
./setup.py:            db_inc_paths.append('/usr/local/BerkeleyDB.4.%d/include' % x)

(Are items installed outside of your --prefix?  Which ones?  What about dependencies compiled outside of /usr/local?)


###################
A terrible solution

It seems most UNIX package managers elect some form of finding and replace all occurances,  for example,

# dirty deeds, done dirt cheap
for i in `grep -Rl '\/usr\/local' ./*` ; do
   safe sed -i 's#\/usr\/local#\/usr\/mypath#g' "$i"
done

./configure --prefix="/usr/mypath"
...continue the make dance...


#################
A better solution

Prioritize some re-factoring work Python 2.7.3 installation, just enough to get sysadmins like myself by until Python3000 is commonplace...

I'd be happy to help, but as a community outsider, I'm not sure how to make the cleanup work stick.