[Zope-dev] Re: Deciphering Zope Comments

[Philipp von Weitershausen]

Shane Hathaway wrote:
> Hi all,
> 
> I'm trying to get a handle on Zope 3.  I plan to take a bunch of Zope 3 
> modules and combine them in a new way.  The goal is to create for myself 
> a comfortable working environment that lets me run simple code in a 
> small mod_wsgi environment with easy reloading and no ZODB initially.
> 
> To achieve this, I need to understand what's going on in the Zope 3 code 
> base.  While the code itself is easy to understand, there are many 
> comments in the code that suggest changes are coming soon.  Please help 
> me figure out what is meant by these comments.
> 
> The first cryptic comment comes from zope.component.  The _api module 
> starts with this gem:
> 
> # SiteManager API. This needs to get deprecated eventually.

I think this meant to say that the word "Site Manager" has been 
deprecated. Nowadays we just say component registry. In theory. I think 
we just found that renaming things isn't worth all the trouble.

> But... um... everything in the module uses getSiteManager().  The whole 
> component foundation is built on it.  When is it going to be replaced? 
> With what?  By whom?

I think the comment can go. It's the opposite of useful right now.

> I'm assuming for the moment that the comment is a lie, and that 
> getSiteManager() is not going away, since otherwise I have no foundation 
> to build upon.

Yup.

> I think I want to use a threading.local as my site manager.  That way, I 
> can use a different configuration for each WSGI app even if several apps 
> run in different threads of a single Python interpreter.  It looks like 
> the zope.app.component.hooks module does something like what I want, but 
> that module is complicated and lacks comments in the places that matter, 
> so I'm not quite sure what it accomplishes.  I'll add comments to that 
> module if anyone can explain it fully.

zope.component.getSiteManager() is a "hooked" function (using 
zope.hookable). That means it can be replaced by some other 
implementation. zope.app.component.hooks makes use of that. It replaces 
zope.component.getSiteManager() with an implementation that looks up a 
thread local variable (SiteInfo). This replacement is done in the 
setHooks() function which is called some time during Zope startup.

> That led me to the zope.thread module, which is apparently deprecated 
> already, yet zope.app.component still depends on it.  Is that an 
> hysterical accident?

As said previously, zope.thread.local is just a wrapper around Python's 
threading.local module (which was contributed by Jim based on 
zope.thread.local).