[Michael Chermside] > 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. > > After all, it's not like file has lots of useful classmethods... > client code which is not supposed to create new files has no > particular need to access the 'file' object. Oh yes, except > that it may have INSTANCES of 'file' and could access > f.__class__. But if it is RESTRICTED code, then the only > legitimate use of f.__class__ is to do typechecking (it's > arguable whether that is good design, but it does seem to be > a legitimate use), so for restricted code we return something > like this: > > class FakeFile: > def __eq__(self, other): > return other == file > > [...] Are you aware of the original issue, which is that as soon as you have a file *instance* (which might have been given to you by a very restrictive open() variant), you can always get to the file *class* using the __class__ attribute? Access to the __class__ attribute is useful for all sorts of reasons. > Guido writes: > > Re the capabilities discussion, this is Python 3.0 material if I ever > > saw some > > I agree. But I can dream, can't I? <wink> Yes, even for 3.0 this is still a dream... --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