[Zope-dev] Re: Deciphering Zope Comments
Philipp von Weitershausen
philipp at weitershausen.de
Wed Jun 4 09:05:18 EDT 2008
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).
More information about the Zope-Dev
mailing list