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
concise:
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
--
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
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
