[PEAK] Update on Zope X3 compatibility (was Re: Does a PEAK-ized webware esist ?)

[Phillip J. Eby]

At 08:22 PM 1/30/04 -0500, Phillip J. Eby wrote:
>An update: doing 'import zope.interface' before any PEAK imports fixes 
>this with Milestone 3, but PyProtocols requires Milestone 4.  I haven't 
>tried Milestone 4 yet.
>
>It appears as though the actual problem may be due to recent changes in 
>PEAK's 'whenImported()' function.  Apparently, it's possible under certain 
>circumstances for it to cause an already-imported module to be reloaded, 
>and that's where it's breaking zope.interface.  So there's actually a PEAK 
>bug here that needs to be fixed, because I've confirmed it's doing the 
>same thing to the 'peak.config.interfaces' package.  (It just doesn't do 
>anything harmful there.)

I've got a temporary fix.  Change this line (269 in peak.util.imports):

     if '.' in moduleName:

to read:

     if 0:

This will disable double-layered laziness.  (Don't ask, if you don't want 
your brains to leak out your ears.  You have been warned.)  Anyway, it 
appears there's a race condition that can cause a statement like:

from peak.config.interfaces import foo

to first convince Python that it should import the actual interfaces.py, 
and then subsequently, to decide that it needs to reload it, too, in order 
to de-lazy-fy it.

I don't want to disable double-layered laziness if I can avoid it, but 
unfortunately I haven't any idea how to make it work correctly, given my 
new understanding of what's going on.  So for now, you can use the 
workaround, while I figure out what to do in the general case.  I've also 
detected a re-entrancy problem in some of this import magic, and I need to 
fix that too.  It's easier to fix, but unfortunately doesn't cure the 
double-load problem.

I think I may end up needing to rewrite the lazyModule/whenImported 
machinery again.  But if I do, it'll be with much finer-grained tests than 
it's currently using, to verify a wider variety of scenarios.