Jeremy> Posters of c.l.py have suggested both alternatives as the Jeremy> logical choice: (1) import * is dynamic so the static scoping Jeremy> rule ignores the names it introduces, Bad alternative. import * works just fine today and is very mature, well understood functionality. This would introduce a special case that is going to confuse people. Jeremy> (2) Python is a late binding language so the name binding Jeremy> introduced by import * is used. This has to be the only reasonable alternative. Nonetheless, as mature and well understood as import * is, the fact that it can import a variable number of unknown arguments into the current namespace creates problems. It interferes with attempts at optimization, it can introduce bugs by importing unwanted symbols, it forces programmers writing code that might be imported that way to work to keep their namespaces clean, and it encourages complications like __all__ to try and avoid namespace pollution. Now it interferes with nested scopes. There are probably more problems I haven't thought of and new ones will probably crop up in the future. The use of import * is generally discouraged in all but well-defined cases ("from Tkinter import *", "from types import *") where the code was specifically written to be imported that way. For notational brevity in interactive use you can use import as (e.g., "import Tkinter as tk"). For use in modules and scripts it's probably best to simply use import module or explicitly grab the names you need from the module you're importing ("from types import StringType, ListType"). Both would improve the readability of the importing code. The only place I can see its use being more than a notational convenience is in wrapper modules like os and re and even there, it can be avoided. I believe in the long haul the correct thing to do is to deprecate import *. Skip