>> If in 2004 certain Python programs written in 2000 or earlier would >> start raising ImportError exceptions on 'from types import *' after >> upgrading to a new system which may come with the latest version of >> Python, this will certainly cause damage. aahz> This can be solved by a combination of changing the documentation aahz> and using __all__ (which I think is in part precisely the point of aahz> creating __all__). I don't think __all__ would help here. The problem as I see it is that the docs say "from types import *" is safe. If you add new names to the types module, they would presumably be added to __all__ as well, and then "from types import *" could clobber local variables or hide globals or builtins the programmer didn't anticipate. So, if we add an object named "function" to the types module and Peter's stable code has a variable of the same name, it's possible that running on a new version of Python will introduce a bug. Still, I have to quibble with Peter's somewhat extreme example. If you take a stable system of the complexity of perhaps Linux or Windows and upgrade it four years later, Python compatibility will probably only be one of many problems raised by the upgrade. If you have a stable program, you try to leave it alone. That means not upgrading it. If you modify the environment the program runs in, you need to retest it. If you write in C you can minimize these problems through static linkage, but the problem with Python is no different than that of a program written in C which uses shared libraries. Names can move around (from one library to another) or new names can be added, giving rise to name conflicts. I seem to recall someone reporting recently about another shared library which defined an external symbol named "socket_init". Skip