[Python-Dev] PEP: Post import hooks

[Phillip J. Eby]

At 12:08 AM 1/11/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > Yes, that's the general idea.  But what happens if you are in the middle
> > of firing hooks for 'a', and a new hook for 'a.b.c' is added?  What
> > about a new hook for 'a'?
>
>If 'a' registers a new hook for a child of 'a' (e.g. 'a.b.c' or 'a.f')
>then the new hooks are called with the remaining hooks for 'a.b.c':
>
>import a.b.c
>* hook_a1
>* hook_a1 -> registers the hook_ab2 for 'a.b'
>* hook_ab1 -> registers a hook_aX for 'a'
>    hook_aX is fired immediately
>* hook_ab2 -- the hook registered by hook_a1

This scenario isn't specific enough to produce/deduce the problem.


> > Well, it certainly can (and should) do the same if a module object is
> > provided, since the module has a __name__.
>
>Maybe I should add two methods to imp. One that calls the parent hooks
>of a module automatically but relies on the existence of the parents and
>the module in sys.modules.
>And a second method which calls the hooks for a module object w/o
>inspecting sys.modules.

*sigh*.  We seem to be getting further and further off course, 
here.  The more different you make the semantics of the system, the 
harder it will be to verify that it's doing the right thing without 
having real field experience with the new approach.


> > Only if you can guarantee that no hook for a submodule is run until all
> > the parent hooks are finished being called *and* that adding new
> > callbacks while callbacks are being run will still call them... *after*
> > any already-added callbacks.
>
>Uhm, now it starts to become a mind bending problem. I may have to queue
>and delay the registration of new hooks while other hooks are called by
>the system. If an user registers a callback for 'a' while the callbacks
>for 'a' are called than the registration is queued and the called after
>the remaining hooks for 'a' are called. This could probably be
>implemented by *not* setting the entry to None after I get hold of the
>iterator but after the end of the iteration. iter() notices when a new
>element is appended.

Yep - that's precisely what peak.util.imports does, and is why it 
does it that way.

However, it has other ways of guaranteeing that the notification 
callback occurs only once, because the module object keeps track of that.


>In the above sample can hook_aX be called after hook_ab1 or should it be
>called after hook_ab2?

That question can't be answered from the limited information you 
supplied about the scenario. What must not happen is that hook_aX 
must not be called before any *already-registered* hooks for 'a'.