On 7/7/06, Brett Cannon <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
