Mark Seaborn wrote:
During the past couple of months I have been working on an object-capability subset of Python - in other words, a restricted execution scheme for sandboxing Python code. It has been influenced by other object-capability subset languages, such as Joe-E (a subset of Java [1]), Caja/Cajita (subsets of Javascript [2]) and Caperl (based on Perl [3]). I'm calling it CapPython because the name doesn't seem to have been taken yet. :-)
No wonder ;-). I like CapPy better, though there is a shareware screen capture program by that name. PyCap is taken. CapThon is not.
I believe it is now secure, so it seems like a good time to announce it here! The basic idea behind CapPython is to enforce encapsulation by restricting access to private attributes of objects. This is achieved through a combination of static checking and limiting access to unsafe builtins and modules. Private attributes may only be accessed through "self" variables. "Self" variables are defined as being the first arguments of functions defined inside class definitions, with a few restrictions intended to prevent these functions from escaping without being safely wrapped.
What about functions defined outside class definitions and then attached as an attribute. Prevented?
Private attribute names are those starting with "_". Additionally, "im_self", "im_func" and some other special cases are treated as private attributes.
In 3.0, unbound methods are gone and im_self and im_func are __self__ and __func__ attributes of method objects.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
