Zope 2.5.1, Python 2.2.1 (yes, I know it's not supported yet <grin>).

I just spent a day tracking down a weird initialization problem
in Zope2.  If you have the following circumstances:

1) an instance of a calss from a Product already in the ZODB
2) your Product 'initialize' uses __import___ to do the import
        of the module containing the class that defines the instance
3) you introduce a bug into the module imported via __import__

then the end result is that the bug in the imported module is
completely swallowed.

The possible Zope buglet:

This happens because the ClassFactory does a bare try/except when
importing the module needed to resucitate the existing object.
This is a reasonable thing for it to do:  if the import fails
for *any* reason it marks the object as broken. It then
logs an error.

I did not, by the way, to figure out why the object got activated
before the install_products call (it was in the top level folder;
that may have something to do with it), but pretty much anything
that touched the Control_Panel (or maybe even app itself) triggered
the load.  I didn't try very hard to figure out why this was

When install_products *does* later run, in normal situations
the product install triggers the same error that ClassFactory saw,
and the developer gets to see the traceback for the bug
he introduced.  But because of the semantics of __import__
(see below), if __import__ was used to load the module-with-bug,
the traceback will *not* happen; and likely some other
error will instead, because the module was not completely loaded.

(NB: It took longer for me to find this bug than it should
have because I forgot to delete my Product from the Control_Panel;
because it was still in there from when it had been working,
ClassFactory did not print it's helpful error message.
I don't know why it didn't, and have not tried to find out).

To fix this theoretical buglet, it might be appropriate for
ClassFactory to log the error rather than just a generic "can't
load" error message.  Yes, normal errors will then appear in
stupid_log twice, but I'd rather two copys of a traceback than a
misleading one.

The Possible Python Bug:

The, um, interesting semantics of __import__ are demonstrated by
this short test program:

try: module = __import__('test2')
except: pass
module = __import__('test2')
print dir(module)

aaa = 'bbb'
raise KeyError
bbb = 'ccc'

If you do 'import test' from the python shell, you will see that
you get no traceback from the second __import__, and further that
'aaa' and only 'aaa' is in the resulting module's __dict__.

It seems to me that this is a bug, but since __import__ is
normally-behind-the-scenes magic, there may be a good reason
for it.  However, if that is the case, how can I check,
when doing an __import__, that I've gotten a valid module?

Concluding Question:

So, which bug tracker does this one go in, zope's or python's?


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to