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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4