forcing future re-import from with an imported module

[Gabriel Genellina]

En Fri, 12 Dec 2008 19:44:32 -0200, _wolf <wolfgang.lipp at gmail.com>  
escribió:

> On Dec 11, 12:43 am, rdmur... at bitdance.com wrote:
>> "Why can't you have the code that is doing the import [...]
>> call a function [...] to produce [the] side effect [...]?
>> Explicit is better than implicit.  A python programmer is
>> going to expect that importing a module is idempotent"
>
> you’re completely right that `import foo` with side effects may break
> some expectations, but so do all `from __future__` imports. you’re
> also right that another solution would be to come in from the other
> side and explicitly call a function from the importing module. all of
> this does not answer one question tho: why does deleting a module work
> most of the time, but not in the case outlined in my first post,
> above? why do we get to see this slightly strange error message there
> complaining about ‘not finding’ a module ‘in sys.modules’—well, most
> of the time, when a module is not in that cache, it will be imported,
> but not in this case. why?

The import system can be customised in many ways (the various import  
hooks, special entries in sys.path, meta_path, path_hooks, __import__,  
etc.), even could be completely reimplemented. There are safety checks in  
the interpreter, to validate some minimal pre and postconditions that  
should always hold.
By example, checking that sys.path contains a list of directories. Or the  
one you broke: after successfully executing "import foo", there must be an  
entry named "foo" in sys.modules. If not, it is asumed that something in  
the import machinery went wrong.

-- 
Gabriel Genellina