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.


On Wed, Mar 10, 2010 at 8:05 PM, Jim Fulton <j...@zope.com> wrote:
> On Tue, Mar 9, 2010 at 6:15 PM, Tim Hoffman <zutes...@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
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to