[Python-Dev] object capability; func_closure; __subclasses__
Phillip J. Eby
pje at telecommunity.com
Thu Jun 28 17:03:32 CEST 2007
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
>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. :)
More information about the Python-Dev