Hi, You might want to try peak.utils.proxies [1] as an alternative for zope.proxy. With some modifications it worked for me on Google App Engine with most (but not all) of the the functionality needed by zope.location. Also this link [2] may (or may not) be a good starting point if you would like to work on this. I'm also interested in porting zope.proxy to pure python, so count me in if you're planning to do some work here. [1] http://pypi.python.org/pypi/ProxyTypes/0.9/ [2] http://bitbucket.org/attilaolah/miniztk/src/tip/zope.proxy-3.5.0-gae-r1/ Attila

Hi As Attila pointed out, zope.proxy is possible to implement using peak.util.proxies if you only want some limited zope.proxy support. You won't get zope.security going down this path. I do that specifically so that I can use zope.deferredimport on app engine. Below is the awful hacking I do to zope.proxy.__init__ to make it support zope.deferredimport on appengine. Rgds T =========================================================== from zope.interface import moduleProvides from zope.proxy.interfaces import IProxyIntrospection from peak.util.proxies import ObjectProxy class ProxyBase(ObjectProxy): pass def getProxiedObject(obj): if hasattr(obj,'__subject__'): return obj.__subject__ else: return obj def removeAllProxies(obj): return getProxiedObject(obj) def sameProxiedObjects(obj1,obj2): if getProxiedObject(obj1) == getProxiedObject(obj2): return True else: return False moduleProvides(IProxyIntrospection) __all__ = tuple(IProxyIntrospection) def ProxyIterator(p): yield p while isProxy(p): p = getProxiedObject(p) yield p def non_overridable(func): return property(lambda self: func.__get__(self)) On Wed, Mar 10, 2010 at 1:03 AM, Jim Fulton <jim@zope.com> wrote:

On Tue, Mar 9, 2010 at 10:53 AM, Baiju M <mbaiju@zeomega.com> wrote:

...

Hi,   Any idea how difficult it is to create optional C extensions for these packages:

zope.container zope.hookable zope.proxy zope.security

I believe it is very hard, if not impossible, for zope.proxy and zope.security.  I suspect the best approach would be to make a new package (or set of packages) that provides everything that zope.security providex except the zope.security.proxy package.  If I were going to do that though, I would rethink the way proxies and checkers are managed.

Jim

-- Jim Fulton _______________________________________________ Zope-Dev maillist  -  Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev **  No cross posts or HTML encoding!  ** (Related lists -  https://mail.zope.org/mailman/listinfo/zope-announce  https://mail.zope.org/mailman/listinfo/zope )

Hi Jim Yeah I agree with you. I haven't ever distributed that version of zope.proxy , just used it internally to support deferredimport. zope.security could never to what it does with a pure python version of zope.proxy. the 'c' wrappers are very important to ensure security. Unfortunately I needed deferredimport and was completely unsure how else to proceed at the time. I use code generation for gae based models, and the unfortunately reference entities need actual models/classes which means you can very easily create cyclic dependancies. Storm allows references to be defined "strings" such as "model.MyClass" but gae doesn't implement such a thing, so deferredimport was the next best thing. T On Wed, Mar 10, 2010 at 8:05 PM, Jim Fulton <jim@zope.com> wrote:

On Tue, Mar 9, 2010 at 6:15 PM, Tim Hoffman <zutesmog@gmail.com> wrote:

...

Hi

As Attila pointed out, zope.proxy is possible to implement using peak.util.proxies if you only want some limited zope.proxy support.  You won't get zope.security going down this path.

I do that specifically so that I can use zope.deferredimport on app engine.

Below is the awful hacking I do to zope.proxy.__init__ to make it support zope.deferredimport on appengine.

Please don't encourage this.

People reading this, please forget you read Tim's email. :) (Jim whips out special pen and asks that everyone look in his direction for a moement.)

zope.deferred import should, perhaps, be modified to use peak.util.proxies, but we should not have packages floating around that modify zope.proxy to weaken it.

I wish I had agitated to make changes to Python to make deferred imports use of zope.proxy unnecessary.

Jim

-- Jim Fulton

On Thu, Mar 11, 2010 at 00:46, Jim Fulton <jim@zope.com> wrote:

On Wed, Mar 10, 2010 at 7:17 AM, Tim Hoffman <zutesmog@gmail.com> wrote: ...

...

Unfortunately I needed deferredimport and was completely unsure how else to proceed at the time. I use code generation for gae based models, and the unfortunately reference entities need actual models/classes which means you can very easily create cyclic dependancies.  Storm allows references to be defined "strings" such as "model.MyClass"  but gae doesn't implement such a thing, so deferredimport was the next best thing.

I thought about this a bit and realized that I could implement deferred import without using proxies. I don't know why I didn't think of this before.

Then I looked at the "Importing" project, which provides the peak.util.imports package:

 http://peak.telecommunity.com/DevCenter/Importing

This looks like a good alternative to zope.deferredimport.  Maybe we should deprecate zope.deferredimport in favor of Importing.  If there are interesting things that depend on zope.deferredimport that we don't want to update, we could reimplement zope.deferredimport using Importing.

+1 for Not Invented Here things. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64