Cameron Simpson wrote:
> On 14Jun2009 16:42, Mark Seaborn wrote:
> | I use a convenience function like this, so that GC takes care of the FDs:
> |
> | def make_pipe():
> | read_fd, write_fd = os.pipe()
> | return os.fdopen(read_fd, "r"), os.fdopen(write_fd,
Facundo Batista wrote:
> errpipe_read, errpipe_write = os.pipe()
> try:
> try:
> .
> .
> .
> .
> .
> .
> finally:
> os.close(errpipe_write)
> .
> .
> .
> finally:
> os.close(errpipe
I have been doing some work to extend Google's Native Client [1] to
support dynamic linking [2]. For those who haven't heard of it,
Native Client is a sandboxing system for running a subset of x86 code.
It is proposed as a way of running native code inside web apps.
One of my aims has been to get
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 18, 2008 at 2:15 PM, Mark Seaborn <[EMAIL PROTECTED]> wrote:
> > Yes. The renaming of "im_self" and "im_func" is good. The removal of
> > unbound methods is a *big* pro
Terry Reedy <[EMAIL PROTECTED]> wrote:
> Mark Seaborn wrote:
> > Private attributes may only be accessed through "self" variables.
> > "Self" variables are defined as being the first arguments of functions
> > defined inside class definitions,
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 o
