Tarek Ziadé wrote:
Jim Fulton wrote:

- Look at opprtunities for limited robust reload.  Perhaps we could
 define reloadable modules, especially for defining adapters,
 with restrictions on their definitions and exports in a way
 that allows robust reload.  This would probably be based on the
 persistent-module experiments.  This is a fair bit of deep work
 though and I'm not sure who has the interest and ability to make
 it happen.

I'm really not interested in a reload faclity, like the one commonly
used in Zope 2, that is not robust.  I've wasted too many hours
helping people debug problems that were caused by reload misshaps.

out of curiosity, what are the things that make a reload not robust ?
is it just a matter of dependencies or it's deeper ?

I was hoping that someone else would answer this directly. :)
Shane did largely answer it, but I'll try to be more direct and

When you reaload a module, the module source is recompiled and
executed.  Values defined in the new version overwrite values of
the same name in the old version.  This has lots of implications:

- Client modules that imported names using from:

    from oldmodule import somename

  Don't see the update.

- Instances of classes defined in the module remain instances
  of the old classes.

- Writable global data is overwritten.  This is a common source
  of subtle bugs when a module defines a registry or cache.

There are probably other interesting things I'm not thinking of.

There are ways of working around these issues, but they require
special techniques that aren't always followed or can be defeated.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to