"Phillip J. Eby" pje@telecommunity.com wrote:

There's a *much* simpler way to do this. 'import' is implemented by calling an '__import__' function -- which of course is a capability. To do mediated imports, it's only necessary to supply a mediating version of '__import__'. One also needs a specialized version of '__import__' to set up a newly imported module's builtins.

I'm aware of this feature, but I was groping for a more elegant (and more capability-flavored) way to do it.

As far as I can tell, the technique you describe is the "policy mini-language" way to implement access control. If I want a certain chunk of code to have access to a certain module, I set the policy with an overridable handler or a configuration object, specifying that this code is allowed to have access to this module, and then I invoke the code.

This is analogous to "restricted Python v2"'s way of controlling access to certain resources in this e-mail message [1].

If I change my mind about how the code should work, I have to make changes in two places: first the part of the code that says "import spam" has to change to say "import eggs", and second the policy configuration has to change from "suchandsuch is allowed to import spam" to "suchandsuch is allowed to import eggs".

In a pure capability language like E, whenever a module is imported it comes into life without permission to do anything, and then the importer grants it permission to do whatever it needs to do (by passing references). This is more like "restricted Python v3" in that designating which module the code ought to use, and authorizing the code to use that module, are both done in the same act (by passing a reference to the module in question).

There is a description with examples in the "E in a Walnut" book [2].

Regards,

Zooko

http://zooko.com/ ^-- under re-construction: some new stuff, some broken links

[1] http://mail.python.org/pipermail/python-dev/2003-March/033938.html [2] http://www.skyhunter.com/marcs/ewalnut.html#SEC16