[Python-Dev] Capabilities

[Ka-Ping Yee]

On Mon, 10 Mar 2003, Jim Fulton wrote:
> Ka-Ping Yee wrote:
> > Here's a preliminary description of the boundary between "introspective"
> > and "restricted", off the top of my head:
> >
> >     1.  The only thing you can do with a bound method is to call it
> >         (bound methods have no attributes except __doc__).
>
> Well, I see no harm and much usefulness
> in allowing __name__, __repr__, and __str__.

Depends.  In a truly secure system, classes would only reveal
information about themselves if they wanted to.  The default
__repr__ gives away to the id() of the instance, and __name__
gives away the name of the method, which would prevent you
from creating proxies that are indistinguishable from the
original.  Sometimes it is useful to be able to do that.

> >     2.  The following instance attributes are off limits:
> >         __class__, __dict__, __module__.
>
> I generally want to be able to get the __class__. This is harmless
> in my case, because I get a proxy back.

We definitely do not want to provide access to __class__.
Access to an instance should not give you the power to create
more instances of its class.  If you passed somebody a file
object, access to the class would convey the power to open any
file on the filesystem!

> > However, there is still the problem that the established technique
> > for storing instance-specific state in Python is to use globally-
> > accessible data attributes instead of a limited scope.  We would
> > also need to add a safe (private) place for instances to put state.
>
> I'm don't understand why this is necessary. In general, you want to
> restrict what attributes (data, properties, methods, etc.) are accessible
> in certain situations. I don't follow what makes data attributes special.

Instances currently don't have a private place to put their state,
and unless there is a convenient way do that, implementers will
tend to expose their instance state in public data attributes.

Even if the instance had properties, the properties still (as yet)
have no way to conveniently distinguish if access is being attempted
from within an instance method, or from outside the instance.


-- ?!ng