Durability and backward compatibility over 10 years...

[Gabriel Genellina]

En Wed, 19 Dec 2007 08:10:59 -0300, Philippe DAVID  
<philippe.a.david at 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