> Michael Chermside <mcherm at mcherm.com>: > > > Suppose that had some code which had an object representing a > > directory, with a method "open(filename, mode='r')" that opened > > files in the directory. Given this object, you could imagine > > constructing new objects with more limited capabilities. Greg Ewing: > With regard to files, we'd almost have something like that > now, if it weren't for the unfortunate fact that the file > type's constructor can be used to open any file. Good observation. > 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? I think so. But to remedy this, the file constructor could simply refuse to open any files when called from restricted mode. (Although this would open up the same kind of holes that Samuele so cleverly showed exist in other built-ins that do this kind of checking.) (Re the capabilities discussion, this is Python 3.0 material if I ever saw some; no time to respond in more detail, given that we've had this thread before.) --Guido van Rossum (home page: http://www.python.org/~guido/)
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