[Python-Dev] doc for new restricted execution design for Python (original) (raw)

Brett Cannon brett at python.org
Fri Jul 7 19:03:40 CEST 2006

On 7/7/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:

Brett Cannon wrote: > On 7/5/06, Greg Ewing <greg.ewing at canterbury.ac.nz_ _> And I would change file() so that it didn't open > files. Then it would be harmless for code to have > access to the file class. > Right, that is essentially what I proposed initially with the whole > crippling idea. > > What the capabilities supporters are saying is that if we go that route > we will be constantly finding objects that require similar crippling. We've got our wires crossed somewhere. I am a capabilities supporter. But for a capability model to work, the capabilities need to be isolated and encapsulated in functions or objects that can be independently provided or not provided. In the case of file(), that means separating the capability of being able to open a file from the capability of accessing an already-opened file. These two things are currently conflated in the file class.

OK, putting that way makes sense for labelling it as capabilities support. It just seems like everyone else who has been calling for more capabilities have not been wanting to change file() in any way.

BTW, I object to the term "crippling" in this particular

case. If you have access to open(), there's no need for file() to be able to do the same thing. And if you don't have access to open(), it's because someone doesn't want you to be able to open files.

But, from the perspective of what file() can do now, it is losing an ability that it once had and not quite as powerful as it was.

-Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060707/5f5280f6/attachment.htm

More information about the Python-Dev mailing list