[Zope-dev] Optional C extensions

[Tim Hoffman]

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 at zope.com> wrote:
> On Tue, Mar 9, 2010 at 6:15 PM, Tim Hoffman <zutesmog at 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
>