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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4