[Zope3-dev] Re: Google SoC Project

[Jim Fulton]

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:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org