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

[Samuele Pedroni]

> 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.