On Tue, May 19, 2009 10:03 am, Ian Forbes wrote:
> correct byte compiled version. Lenny does not have Python 2.6.
>
> (In general I try to install as much as possible from the distribution,
> this has worked well in the past with Debian, sometimes Ubuntu can be a
> touch to close to the bleeding edge. When I get time I will test it
> under python 2.6 with "compile_package")

I'm rather the opposite as I like many of the newer features in recent
Python versions and don't need to worry about backwards compatibility.
Rather deliberately I'm trying to stay close to the front edge of Python;
2.6 I like for multiple reasons including that it takes us along the road
to 3.x, and it also sports a performance increase which appears to help QP
and I suspect Quixote will like it too, although probably the difference
isn't material enough to worry much about since other components of a Q
app are going to be more likely bottlenecks.

To avoid clobbering your system version of Python you can always issue
"make altinstall" when building (which may be the default behaviour these
days) -- it will install Python2.x but not change /usr/local/bin/python to
that version, thus keeping whatever else depends on that specific version
intact.

Potential operator confusion to keep in mind: I have QP (and for a time an
old Quixote) apps running on the same server on Python 2.5 and 2.6 and
3.1b1+. For some package's executable scripts I have to preface the script
with python2.x or python3.1, since the bang line in the script often can
have a Python version which is not the system's "default" version. We are
doing this to move all our apps to 3.x; so our base system version we've
made 2.6 and when we have to deviate we prefix the application startup
script with a small script that sets up an environment and starts the app
with the right Python. It isn't as confusing as it appears.