Here's a high-level response to this thread.

As others have pointed out, zope.component and zope.interface should work fine without the C optimizations and I'm in favor of changing the setup to make them installable without the optimizations.

zope.proxy is harder. :( What's especially sad is that the dependency on it is rather unimportant. It is used by zope.deferredimport. I was forced to use proxies because of annoying limitations in Python's module implementation and the inspect module's assumption that a module is not a module unless it subclasses the standard Python module type. I expect though that a simpler proxy implementation could be used by deferredimport. This would make zope.component depend on zope.proxy only if the annoying zcml is used.

I'd love to see both of the above fixed, but, sadly, don't have time to fix them myself any time soon.


On Apr 18, 2008, at 7:43 PM, Darryl Cousins wrote:

"The ZCA framework is developed as part of the Zope 3 project. As noted earlier, it is a pure Python framework, so it can be used in any kind of
Python application." [1]

I was hoping to try using ZCA for a googleappengine experiment. Using
Ian Bickings post [2] I set up a environment to install zca packages.

zope.interface and zope.proxy both have .so files that aren't usable in
a gae project. ( and

From the quote above and other mentions on the web I gather that there
exist pure-python ZCA packages. Could someone point me to where to find

Best regards,


Zope3-users mailing list

Jim Fulton
Zope Corporation

Zope3-users mailing list

Reply via email to