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 exercise.
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 like this: ZipFile(already_opened_file) 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. Paul Prescod