Gabriel Genellina
12/20/2007 12:32:00 AM
En Wed, 19 Dec 2007 08:10:59 -0300, Philippe DAVID
<philippe.a.david@sogeti.com> escribió:
> I would like to use python to write some scripts for a system that will
> be used
> for more than 10 years. My problem is the following:
> In 10 years, if the OS evolves and ships with the latest stable version
> of
> python, is there a chance for my 10 year old scripts to run on the new
> system ?
> (I am using the following imports: os, sys, md5, getopt, socket,
> UserDict).
> Currently we are using a RHEL linux, it includes python 2, 2.3 and 2.5.
> How old
> is this python 2 ?
2.0 is from October 2000, that's seven years old. Some people is still
using an even older version, 1.5.2.
Note that a script written for Python 1.5 likely runs without changes
using today's version. A script written now for 2.5 probably will run
unchanged for any upcoming 2.X release. The break point is at 3.0 - that
version is not backward compatible by design (but there is a tool to
automate the conversion 2 to 3).
Forcing my crystall ball, I think RH will include 3.X and 2.X versions of
Python for a long time.
> I don't need to be 100% sure that it will work, but avoiding upgrades of
> the
> scripts would be a significant plus.
Python has a rather impressive backward compatibility history. I think the
environment changes will be more important than Python itself (64bits to
xxx?, multiprocessor architecture, IPv6).
> Otherwise, is it possible to do something similar like static compiling
> in C ? I
> mean having one file, or a little set of files that contain my scripts
> and what
> is needed from the python libs to run them ? This way I could ship the
> scripts
> and some executables and be pretty much confident it will run even on new
> systems for a long time.
You can always install Python in an alternate place (e.g. your home
directory) and not rely on the system one.
--
Gabriel Genellina