[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:
>rehi all,
>
>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
>doing that?

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 mailing list