Greg Ewing wrote:
> David Hopwood wrote:
>
>> A restricted interpreter refuses access to any object attribute or
>> method with a name beginning with '_' (by throwing a new exception type
>> 'InternalAccessException'), unless the access is from a method and its
>> static target is that method's first argument variable.
>
> What's to stop
>
> def my_naughty_method(self):
> self = some_protected_object
> self._a_special_attribute = some_naughty_value
That's a good point -- I didn't describe the intended restriction correctly.
The reason for not just saying "... and its target is the object that was
passed as that method's first argument", was that I want it to be possible to
reject programs with internal accesses that cannot be statically recognized
as legal.
(This does not mean that a particular implementation would have to rely on
static detection of non-internal accesses, or on a trusted compiler.)
How about this:
A restricted interpreter shall refuse access to any object attribute or
method with a name beginning with '_', unless the access is from a method,
and its target is the object that was passed as that method's first
argument.
If such an access is detected at run-time, then it shall be reported by
throwing a new exception type 'InternalAccessException'.
In addition, a program containing an access to an object attribute or
method with a name beginning with '_', where the access is not from a
method, or the target of the access is not the method's first argument
variable, or there is an assignment to that variable in the method, is
an illegal program.
>> __init__ is an internal method. This is as it should be, because it
>> should not be possible to call __init__ on an existing object
... from outside the object, that is ...
>> ; only to have __init__ implicitly called when a new object is constructed.
>
> What about calling an inherited __init__ method?
> Your proposed rule would seem to disallow
>
> BaseClass.__init__(self, ...)
No, this call would be allowed because it is to self.
--
David Hopwood <[EMAIL PROTECTED]>
_______________________________________________
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
