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

Samuele Pedroni pedronis@bluewin.ch
Fri, 21 Mar 2003 00:54:21 +0100

Samuele Pedroni <pedronis@bluewin.ch>:

> The problem is that normally modules are uniquely globally identified > singletons, but the very notion of parametrization implies instantiation and > that breaks the singleton part.

to makes things clearer

Python already has things you can instantiate -- they're called classes!

Python already has things you can parametrize -- they're called classes!

Seems to me if you want instantiation, you should be using a class, not a module.

Seems to me if you want parametrization, you should be using a class, not a module.

Maybe.

[ what is sometimes called a "unit" that means a parametrizable and instatiable module can be a useful generic-programming construct. ]

the underlying questions is how much cap-Python programming can be like/we want it like current Python programming?

for example concretely,

module and imports are often used to access "program-wide" factories. Do we want cap-confined client code to be rewritten in order to pass the factories or single factory-constructed objects otherwise:

[Zooko]

So one design for cap-Python might say that only safe modules can be imported by cap-Python code. Every unsafe privilege would have to be granted by using references (passed as arguments, assigned to variables, etc.). No authority would ever be made available to capability-secured code through "import".

or not.

There are trade-offs in terms of necessary semantics changes/complexity vs. language overall feeling preservation and legacy code reuse and adaptation.