On 7/7/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Good point. C code could circumvent the bit check by doing all of the work behind the scenes without pushing the object on the stack. But if the check is in the C code for the object itself it is much harder to get around.
-Brett
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()))().
Good point. C code could circumvent the bit check by doing all of the work behind the scenes without pushing the object on the stack. But if the check is in the C code for the object itself it is much harder to get around.
-Brett
_______________________________________________ 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
