Python 3.0 will be backward incompatible

[John Gilmore]

> #!/usr/bin/python2.5 works for me.

Works on the OLPC and on some Linuxes.  Not everybody puts Python
in /usr/bin, unfortunately.  That's a local system dependency, rather
than a global constant -- but there it is in your portable Python
program.  :-(

I've seen others do "#!env python2.5" which at least has the benefit
of not hardwiring the execution path.  It also requires a second small
executable, which is widely available in Unix/Linux systems as part of
the GNU Coreutils (and busybox).  But are you sure that python2.5 is the
name of Python 2.5 everywhere?  Not "python-2.5", not "python.2.5",
not "python_2.5", not "Python 2.5"?

I think it would be better to have a system library that would 
re-execute a different interpreter (in a system-dependent way) if
the one that started this Python program wasn't an acceptable version.
Thus you could use #!python, then something like:

import pyversion from pyversion
version.enforce(2.5)

This could be implemented in an arbitrarily complex way, such as:

  *  return immediately if the right version is running.
  *  Complain bitterly if this is a second call and demands a different version
     than the first call (e.g. main program wants 2.4, library wants 2.5).
  *  Complain bitterly if the main program has done something irrevocable
     before this call, and thus exec() won't do the right thing.
  *  exec() the right version if it's installed elsewhere in the system.
  *  Unpack the right version from a tar file into a cache directory, exec it.
  *  Try "apt-get install python-$version" and then exec it.
  *  Try doing a home-directory apt-get if you don't have system install
     permission (a la "xo-get").
  *  Check the mesh to see if any nearby laptop has it.
  *  ...etc...

	John