[Python-Dev] object capability; func_closure; __subclasses__

[Phillip J. Eby]

At 01:09 PM 6/28/2007 +0100, tav wrote:
>>You know, I find it particularly interesting that, as far as I can
>>tell, nobody who proposes making changes to the Python language to
>>add security, ever seems to offer any comparison or contrast of their
>>approaches to Zope's -- which doesn't require any changes to the 
>>language.  :)
>
>Whilst it is definitely possible to build up a object capability
>system with a pruned down version of Zope 3's proxy + checker
>mechanism, it ends up in a system which is quite performance
>intensive. All those proxies being wrapped/unwrapped/checked...
>
>In contrast, the mechanism I am looking at here simply requires
>*moving* just 2 attributes *out* of the core builtins...
>
>Quite cheap, simple and effective, no?
>
>>Well, you're missing a simpler approach to protecting functions,
>>anyway.  The '__call__' attribute of functions is still callable, but
>>doesn't provide any access to func_closure, func_code, etc.  I
>>believe this trick also works for bound method objects.
>
>Whilst that would have been a nice trick, what about __call__.__self__ ?

Well, there's no __self__ in 2.3 or 2.4; I guess that was added in 2.5.  Darn.


>Or, setting __call__.__doc__ ?

What does that do?


>>I suspect that you could also use ctypes to remove or alter the
>>type.__subclasses__ member, though I suppose you might not consider
>>that to be "pure" Python any more.  However, if you use a definition
>>of pure that allows for stdlib modules, then perhaps it works.  :)
>
>Ah, thanks! Will look into that.

If it works, you could probably do the same thing to remove __call__.__self__.


>I don't object to making func_closure writable either. In fact, as
>someone who has been following your work on generic functions from way
>before RuleDispatch, I really want to see PEP 3124 in 3.0
>
>But, all I am asking for is to not expose func_closure (and perhaps
>some of the other func_*) as members of FunctionType -- isn't it
>possible to add functionality to the ``new`` module which would allow
>one to read/write func_closure?

In 3.0, I don't mind if the access method moves, I just want to keep 
the access.  OTOH, I don't really care about __call__.__self__, since 
I got along fine without it in 2.3/2.4 and didn't know it had been 
added in 2.5.  :)