On 7/7/06, Brett Cannon <brett at python.org> wrote: > I guess I am just not seeing where your approach is better than preventing > the constructor in 'file' and having open() return the 'file' object or > proxy object. With your approach 'file' would be flagged, but with the > other you just put the same check in 'file's constructor. With both you > would probably also want open() to be a factory function anyway. So I don't > see where you gain simplicity or more security. It seems like you are > pushing the check into the eval loop, but you still require the flagging of > objects as unsafe. Going with the other two proposals you don't burden the > eval loop with the check but the objects that you would have flagged in the > first place. > > It just seems like we are pushing around the flagging of unsafe stuff and > that doesn't feel like it buys us much. At the risk of repeating someone's point or making no sense (I'm only following this with half an ear) I would like to point out that as long as there's C code involved, we can have the equivalent of private constructors in C++/Java. This means classes that cannot be constructed by calling the class from Python. C code has to use some other API to create an instance, bypassing this check. It seems reasonable to me, even if most popular types *can* be constructed. There are other types that have this property, e.g. list iterators. Try type(iter(list()))(). -- --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