[Python-Dev] object capability; func_closure; __subclasses__
Phillip J. Eby
pje at telecommunity.com
Thu Jun 28 06:41:35 CEST 2007
At 02:04 AM 6/28/2007 +0100, tav wrote:
>I have been looking at the object capability + Python discussions for
>a while now, and was wondering what the use cases for
>``object.__subclasses__`` and ``FunctionType.func_closure`` were?
>I don't see __subclasses__ used anywhere in the standard library. And
>whilst I can see exposing func_closure as being useful in terms of
>"cloning/modifying" an existing function, isn't it possible to do that
>without making it introspectable?
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. :)
>Now, whilst probably wrong, I can see myself being able to create a
>minimal object capability system in pure python if those 2 "features"
>disappeared. Am I missing something obvious that prevents me from
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.
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. :)
>Can we get rid of them for Python 2.6? Or even 2.5.2? Is anyone
>besides PJE actually using them? ;p
I wouldn't object (no pun intended) to moving the type.__subclasses__
method to say, the 'new' or 'gc' modules, since you wouldn't want to
make those available to restricted code, but then they'd still be
available for folks who need/want them. 'gc' has similar
capabilities (again no pun intended) anyway.
However, ISTM that this should be a 3.0 change rather than a 2.x one,
even so. With regard to the func_closure thing, I'd actually like to
make it *writable* as well as readable, and I don't mean just to
change the contents of the cells. But, since you can use .__call__
to make a capability without access to func_closure, it doesn't seem
like you really need to remove func_closure.
More information about the Python-Dev