[Python-Dev] PEP 294: Type Names in the types Module

[Skip Montanaro]

    >> 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