Re: CapPython and Python 3.0, and eyebrow-raising applications

zooko <[email protected]> wrote:

> Obviously you should send a note to the [email protected]  
> mailing list [1] letting them know about this, even if it is a  
> foregone conclusion that they don't want to make any changes to the  
> language before the Python 3.0 release.

The topic of unbound methods came up when I announced CapPython on
python-dev and I posted this message:
http://mail.python.org/pipermail/python-dev/2008-September/082499.html

I discovered another problem introduced in Python 3.0: there is an
attribute access syntax in the new format strings introduced in PEP
3101 which can expose private attributes [1].  I'll post about that on
python-3000 soon.

> However, don't despair.  They could change their minds again.  Also,  
> Python 3.0 is backwards-incompatible with Python 2, and so it will be  
> at least a few years if not many years before people stop writing  
> Python 2 code.  You have plenty of time to demonstrate the usefulness  
> of CapPython in the context of Python-2.

Yes, good point.

> How to do that, exactly?  What is the application of CapPython which  
> would raise the most eyebrows and cause the most Python hackers to  
> say "Hey, that *is* cool!"?

That's a good question.

> The web server that runs untrusted Python code is a fine start.  Any  
> other ideas?

One plan is to integrate it with Plash so that there is a safe API for
spawning untrusted processes that can be used from CapPython.

This could be useful for Plash's packaging system.  The logic for
choosing, downloading and setting up packages and their dependencies
is relatively complicated and is currently hardcoded into the package
tools, which run unsandboxed.  It would be good if these parts ran
with less authority.  It would be even better if packages could
provide their own versions of parts of this logic, such as providing a
custom dependency chooser.

If this customisation could be done in a capability language such as
E, Caja or CapPython that would be easier than doing it via
Plash-sandboxed processes, because it avoids a bootstrapping problem.
Setting up an environment to run a process under Plash is a relatively
complex affair.  A file namespace has to be set up and populated with
libraries, which have to come from somewhere, such as from a package,
which is no good if the process's purpose is to set up packages.

Mark

[1] http://lackingrhoticity.blogspot.com/2008/09/attribute-access-in-format-strings-in.html