Michael Chermside <mcherm at mcherm.com>: > Greg: > > In light of this, it may have been a serious mistake to > > unify the 'file' type and the 'open' function. Is it too > > late to back out of that decision? > > Guido: > > I think so. > > I disagree. Right now, having access to a class object basically > gives one the ability to create new objects of that type. I > think that's just fine... and I don't mind applying it to the > file object. I'd think that the thing to do with untrusted code > is to deny it access to the 'file' type object, thus denying it > the ability to create new 'file's directly. It would be a lot better if we could get away from the idea of a "restricted mode" in the sense of a flag somewhere that a bunch of things have to take notice of in order to behave securely, because that model of security is prone to springing leaks -- as happened in a big way when new-style classes were introduced. The spirit behind my suggestion was to start thinking about ways in which functionality could be separated out so that this kind of special-casing for security purposes isn't needed. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg at cosc.canterbury.ac.nz +--------------------------------------+
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