Makefile.pre.in as checked in has several small bugs:

First, the altbininstall target runs "ln -s" without first ensuring the
destination doesn't exist.  If you run "make install" twice, without
manually deleting $prefix/bin/python3 between the runs, the "ln" fails
and "make" aborts.  This happens pretty early in the install process, so
for example this means you can't edit a module in Lib and re-install it.

Second, the bininstall target no longer installs a "python" executable.
 It should hard-link "python" to "python3.1"--as indeed is the entire
point of having the bininstall target--but it doesn't.  (I was quite
surprised by this.  I would have asked the person who removed it--but
"svn blame" doesn't show you who *removed* a line, and I didn't have the
inclination to go bisecting to sleuth it out on my own.)

Third, when altbininstall and bininstall write the "python3.1" and
"python" executables in the prefix directory, they also create
corresponding "python3.1-config" and "python-config" configuration
reporting scripts.  But altbininstall doesn't create a "python3-config"
to go with "python3".

Fourth, maninstall is only run as part of bininstall, not altbininstall.
 This means that you only got the "python3.1" man page if you ran
bininstall, and we all know running bininstall is not recommended.

Fifth, bininstall and altbininstall don't properly honor $EXE; sometimes
they specify it and sometimes they don't.  To be honest I'm not sure
this matters in the slightest.  $EXE is only non-empty for Windows
builds, and Windows has a completely separate build process.  And even
if you used the Makefile to build, I cannot imagine you using it to
install.  Still, a foolish consistency is the hobgoblin of my little mind.

My patch fixes all of the above.  While I was staring at it, I also
touched up some comments.

One final question: why do we use soft-links to "python3.1-config" but
hard links to "python3.1"?