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 > 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. > 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. In the above sample can hook_aX be called after hook_ab1 or should it be called after hook_ab2? > In general, if you think something in peak.util.imports isn't required, > you're probably wrong. ;) *g* ok. I'll check your implementation again. Christian _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
