Mon, 31 Mar 2003 17:08:40 -0800
Guido van Rossum wrote:
>>In many classes, __init__ exercises authority. An obvious C type with
>>the same problem is the "file" type (being able to ask a file object
>>for its type gets you the ability to open any file on the filesystem).
>>But many Python classes are in the same position -- they acquire
>>authority upon initialization.
> What do you mean exactly by "exercise authority"? Again, I understand
> this for C code, but it would seem that all authority ultimately comes
> from C code, so I don't understand what authority __init__() can
Given that Zipfile("/tmp/foo.zip") can read a zipfile, the zipfile class
clearly has the ability to open files. It derives this ability from the
fact that it can get at open(), os.open etc. In a capabilities world, it
should not have access to that stuff unless the caller specifically gave
it access. And the logical way for the caller to give it that access is
But in restricted code
> But is it really ZipFile.__init__ that exercises the authority? Isn't
> its authority derived from that of the open() function that it calls?
I think that's the problem. the ZipFile module has a back-door
"capability" that is incredibly powerful. In a library designed for
capabilities, its only access to the outside world would be via data
passed to it explicitly.
> In what sense is the ZipFile class an entity by itself, rather than
> just a pile of Python statements that derive any and all authority
> from its caller?
In the sense that it can import "open" or "os.open" rather than being
forced to only communicate with the world through objects provided by
the caller. If we imagine a world where it has no access to those
back-doors then I can't see why Ping's complaint about access to classes
would be a problem.