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