Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread 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

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Jim Fulton
Lennart Regebro wrote: On 5/9/06, Jim Fulton [EMAIL PROTECTED] wrote: - Speed up restart. I think there are a lot of ways that restarts can be made faster: [...] o Load less. A Zope 3 application that only loads what it actually uses will load much more quickly than a full

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Jim Fulton
Stephan Richter wrote: On Tuesday 09 May 2006 07:22, Jim Fulton wrote: I guess we need to make this a priority for the next release. Python simply does not support a general robust reload, other than restart. I think that there are 2 ways we can make progress in this area: - Speed up

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Tarek Ziadé
Jim Fulton wrote: 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

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Jim Fulton
Adam Groszer wrote: Hello Jim, Tuesday, May 9, 2006, 1:22:30 PM, you wrote: [snip] JF Python simply does not support a general robust reload, other than JF restart. [snip] What about pushing the problem then to the lower level, to Python itself. I think all developers are fighting the same

Re: reloading modules (was Re: [Zope3-dev] Re: Google SoC Project)

2006-05-12 Thread Jim Fulton
Shane Hathaway wrote: ... 2) Make reloadable code fundamentally different. Yes. If module X is supposed to be reloadable, and X creates a module-level global variable Y, and module Z imports Y, then Y needs to be decorated in such a way that Z's view of Y can change automatically when X is

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Jim Fulton
Dieter Maurer wrote: Jim Fulton wrote at 2006-5-9 07:22 -0400: ... Finally, there's a lot of interest in generating configuration actions in Python, rather than ZCML. I suspect that avoiding XML processing, conversion, and validation might speed startup quite a bit. Moreover,

Re: [Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Stephan Richter
Hi everyone, I just discussed those comments with Jim via IRC. The following comments are FYI. On Friday 12 May 2006 08:56, Jim Fulton wrote: directives have to be reviewed and it must be ensured that they are multi-site aware. The tricky part of the implementation will be to hook in

[Zope3-dev] Re: Google SoC Project

2006-05-12 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: snip The second approach is to reduce the ZCML processing time, which could be integrated into the reload mechanism for Zope 2. This can be accomplished by storing some binary representation of the ZCML, similarly to

Re: reloading modules (was Re: [Zope3-dev] Re: Google SoC Project)

2006-05-12 Thread Shane Hathaway
Jim Fulton wrote: I also think there is a real opportunity in allowing reload to fail. That is, it should be possible for reload to visibly fail so the user knows that they have to restart. Then we only reload when we *know* we can make changes safely and fail otherwise. For example, in the

[Zope3-dev] __contains__ and acquisition problem?

2006-05-12 Thread Florent Guillaume
Could anybody shed some light on what's happening here: from Acquisition import Implicit class Impl(Implicit): ... pass class C(Implicit): ... def __getitem__(self, key): ... print 'getitem', key ... if key == 4: ... raise IndexError ... return