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
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:
>> As Attila pointed out, zope.proxy is possible to implement using
>> 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 Fulton
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -