En Wed, 19 Dec 2007 08:10:59 -0300, Philippe DAVID <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
