[Zope3-dev] Nasty bugs

[Casey Duncan]

I'm sure this is an over-simplification, but couldn't we solve this 
using getbaseobject from ContextWrapper.wrapper?

Such as:

if getbaseobject(baz) is None:
    The bloody thing is none...

or

if isinstance(getbaseobject(spam), ListType):
    I'll be, it's a list...

Perhaps this is introducing a dependancy on wrapper that you don't 
want... On the bright side (or dim) an idiotic implementation of 
getbaseobject could be:

def getbaseobject(ob): return ob

So I guess we either implicitly have a dependancy on wrappers, we 
explicitly need wrapper awareness (like above), we don't wrap 
primitives, or we change Python...8^\

Or....

Maybe we can magically sub in our own isinstance built-in inside of Zope 
that is wrapper aware. But of course that doesn't help us with the "is" 
problem...

Or...

Is there some way that a wrapper can magically be a subclass of whatever 
it wraps? That would also fix instanceof, but not is...

Or...

Just don't ever use primitives ;^)

I really feel like the lesser of all evils right now is to sort of punt 
and not enforce security on primitives, and therefore now allow them to 
be wrapped.

Just one more idea:

A possible change to python where a class could define an __is__ slot 
sorta kinda like __cmp__ where it returns true if the class/instance 
wants to pretend to be something. In wrapper it could be something like:

def __is__(self, other):
     return getbaseobject(self) is getbaseobject(other)

or the C equivilant. That doesn't seem terribly abhorrent, and doesn't 
make Python need to know anything about wrappers... But then again what 
do I know.

-Casey

Steve Alexander wrote:
> Guido van Rossum wrote:
> 
>>
>>     (2a) Why would None need to be wrapped?
> 
> 
> This opens up a larger problem, and one which Shane and I have been 
> discussing at some length on IRC.
> 
> If None is wrapped, we can't expect to use Zope3 directly with 
> third-party modules that say:
> 
>   if foo is None:
> 
> ...as, a wrapped None is not None.
> 
> 
> There's a similar issue around other wrapped primitive types. For 
> example, I recently (with Fred's reluctant blessing) checked in a change 
> to TALDefs.py to stop it checking that a macro is a list, using instanceof.
> 
> This was breaking Page Template macros in Zope 3 because the list would 
> be wrapped, and instanceof(wrapped_list, ListType) is 0.
> 
> 
> (There's another issue here, of why a macro is a list rather than a 
> PageTemplateMacro instance.)
> 
> Fred also recently fixed a bug in wrapper.c, where:
> 
>   for a in Wrapper([1,2,3]): print a
> 
> ... would fail, because wrappers didn't fill the appropriate iterable 
> slot. This bug, in conjunction with wrapping PageTemplate Macros, was 
> causing the ZMI not to work.
> 
> 
> I see a few choices here:
> 
>   1: Zope3 puts constraints on modules it is used with such that they
>      don't use "is", "type" or "instanceof" on anything they don't have
>      full and immediate control over.
> 
>   So, modules to be used with Zope3 should use
>   interface.isImplementedBy, which should be changed to know about
>   wrappers.
>   This seems to go against Zope3's goal of easily interoperating with
>   3rd party python modules.
> 
> 
>   2: Primitive types are never wrapped.
> 
>   This is not such a good idea for security, especially if we're passing
>   around complex structured data (such as in a Page Template Macro).
>   So, this also conflicts with the Zope3 interoperability goal above.
>   Also, I can see this being a problem for the SpaceSuits capability-
>   based security proposal.
> 
> 
>   3: Python is altered to support very transparent wrappers.
> 
>   So, there's some sort of "I'm a wrapper" slot, and type and isinstance
>   and "is" know about this slot and compare unwrapped values.
> 
>   I don't know if this is desirable for type and isinstance, and I don't
>   know if it is possible for "is".
> 
> -- 
> Steve Alexander
> 
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev
>