Home Original page

[Python-Dev] capability-mediated modules (was: python-dev Summary for 2003-03-01 through 2003-03-15)

Greg Ewing greg@cosc.canterbury.ac.nz
Fri, 21 Mar 2003 11:51:06 +1200 (NZST) 
Zooko <zooko@zooko.com>:

> So your proposal seems sort of like a kind of dynamic scoping for
> modules

Yes, it would be dynamic scoping of the import namespace.

The reason I think it needs to be dynamic rather than lexical is that
it isn't really objects or functions that we want to allow or deny
capabilities to, it's *users* (for some suitably general notion of
"user"). It may be okay for a particular method to do something when
it's called by one user, but not another.

The current method of controlling access to modules by overriding
__import__ suffers from the problem that a given module can only have
one __import__ hook at a time.  There's no way for different users of
the same module to have different importing abilities.

>From what's been said about E, it seems that the solution there is to
have instantiable modules (which means they're more like classes than
modules, in Python terms) and to explicitly pass a lot of capabilities
around.

It seems to me that you'd end up with a lot of extra parameters to
pass around in calls that way, and most of the time you'd just be
passing on what had been passed to you -- hence my suggestion of
dynamic scoping.

But, not having studied any real E code, it may be that it doesn't
turn out to be that bad in practice. Probably I shouldn't say any more
until I know what I'm talking about...

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg@cosc.canterbury.ac.nz	   +--------------------------------------+