Phillip J. Eby wrote:
> Sorry about that - as I said, __notified__ is very much an implicit
> thing in peak.util.imports.
>
> And I believe I've also mentioned a lot of times how hard it is to get
> this stuff right... :)
*hehe* Indeed, you did! I should have been warned. :)
> Congrats! Now a
At 04:40 AM 1/16/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > I guess it's not right then. ;-) Though I shouldn't make fun, since it
> > turns out that my code sketch was not a correct translation of
> > peak.util.imports. (See below.)
>
>*gr* I spent more than hour to find
Phillip J. Eby wrote:
> I guess it's not right then. ;-) Though I shouldn't make fun, since it
> turns out that my code sketch was not a correct translation of
> peak.util.imports. (See below.)
*gr* I spent more than hour to find my error ...
> That is, module.__notified__ has to be set *b
At 02:28 AM 1/16/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > At 10:14 PM 1/15/2008 +0100, Christian Heimes wrote:
> >> My code queues up new hooks while a sequence of hooks is processed. It
> >> makes sure that hooks for a parent aren't called in the middle of a
> >> child's hook
Phillip J. Eby wrote:
> At 10:14 PM 1/15/2008 +0100, Christian Heimes wrote:
>> My code queues up new hooks while a sequence of hooks is processed. It
>> makes sure that hooks for a parent aren't called in the middle of a
>> child's hook chain.
>
> Notice that that's not necessary with the notific
At 10:14 PM 1/15/2008 +0100, Christian Heimes wrote:
>My code queues up new hooks while a sequence of hooks is processed. It
>makes sure that hooks for a parent aren't called in the middle of a
>child's hook chain.
Notice that that's not necessary with the notification algorithm I
gave, since the
Phillip J. Eby wrote:
> when_imported('a.b')(func_ab1)
> when_imported('a.b')(func_ab2)
>
> @when_imported('a')
> def func_a1(module_a):
> when_imported('a.b')(func_ab3)
> notify_module('a.b') # <- this is here to foil trivial
> implementations
>
> when_imported('a')(func_a2)
> notify_m
At 10:10 PM 1/11/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > *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 r
Phillip J. Eby wrote:
> *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.
*sigh*, too. :
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 o
At 01:47 AM 1/11/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
> > At 11:45 PM 1/10/2008 +0100, Christian Heimes wrote:
> >> In my version a hook is immediately called when the the registry value
> >> is set to None. When a hook is registered for a module during the
> >> execution of t
Phillip J. Eby wrote:
> At 11:45 PM 1/10/2008 +0100, Christian Heimes wrote:
>> In my version a hook is immediately called when the the registry value
>> is set to None. When a hook is registered for a module during the
>> execution of the callback then the hook is fired directly and not after
>> t
At 11:45 PM 1/10/2008 +0100, Christian Heimes wrote:
>In my version a hook is immediately called when the the registry value
>is set to None. When a hook is registered for a module during the
>execution of the callback then the hook is fired directly and not after
>the existing hooks are called. Is
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 wi
Phillip J. Eby wrote:
>> I'm not setting the hooks to Py_None before the hook are called.
Err, make that NOW, not NOT ... stupid typo.
I'm NOW setting the hooks to Py_None before the hooks are called.
> That's fine, but here's a different catch: are you iterating over the
> hooks by taking the
At 09:40 PM 1/10/2008 +0100, Christian Heimes wrote:
>Phillip J. Eby wrote:
>[...]
>
> > There's also one twist that I haven't sorted out yet: "Importing"
> > guarantees that a parent module 'foo' will have a 'bar' attribute for
> > the 'foo.bar' module, if 'foo.bar' is lazy. It does this by
> > r
Phillip J. Eby wrote:
[...]
> There's also one twist that I haven't sorted out yet: "Importing"
> guarantees that a parent module 'foo' will have a 'bar' attribute for
> the 'foo.bar' module, if 'foo.bar' is lazy. It does this by
> registering a callback, ideally *before* any other callback is
At 07:22 PM 1/10/2008 +1000, Nick Coghlan wrote:
>Christian Heimes wrote:
> > A module is successfully loaded
> > '''
> >
> > The import machinery checks if sys.post_import_hooks contains post import
> > hooks for the newly loaded module. If hooks are found then the hook
Christian Heimes wrote:
> A module is successfully loaded
> '''
>
> The import machinery checks if sys.post_import_hooks contains post import
> hooks for the newly loaded module. If hooks are found then the hooks are
> called in the order they were registered with the m
At 03:20 AM 1/10/2008 +0100, Christian Heimes wrote:
>PyObject* PyImport_NotifyModuleLoaded(PyObject *module)
>Notify the post import system that a module was requested. Returns the
>module or NULL if an error has occured.
The big problem here is that the interaction with laziness is
actu
20 matches
Mail list logo
