[pypy-dev] pypy-dev Digest, Vol 310, Issue 5

[Aurélien Campéas]

On Wed, May 24, 2006 at 09:06:20AM +0200, Grégoire Dooms wrote:
> 
> >Date: Fri, 12 May 2006 12:42:17 +0200
> >From: Aur?lien Camp?as <aurelien.campeas at logilab.fr>
> >Subject: Re: [pypy-dev] Thread cloning (coroutine cloning, really)
> >To: Armin Rigo <arigo at tunes.org>
> >Cc: pypy-dev at codespeak.net
> >Message-ID: <20060512104217.GB28391 at crater.logilab.fr>
> >Content-Type: text/plain; charset=iso-8859-1
> >  
> <snip>
> >We could restrict the programming style for code to be running inside
> >comp. spaces but if it is possible to effectively clone everything
> >(for some ill-defined notion of everything) then it'l be fine. I'm not
> >100% sure. Here are some of the constraints :
> >
> >In principle, side-effects on the parent space and the outer world
> >should be forbidden from within a running comp. space ('cause the jury
> >is still out on its outcome).
> >  
> 
> If I can throw in my two cents, you should really try to remove this 
> limitation of Mozart. This is a real pain in the ass when you want to 
> know what happens in a space (I used to need that in Mozart for 
> debugging or statistics). In Mozart it is possible to use a hack in 
> order to have side effects out of a space (ie modifiy state outside the 
> space)  by using ports.
> I think a design which would allow it would be much more Pythonic (we 
> are between consenting adults :-)

I had been thinking about that indeed. Glad you tell us what you
think. Anyway, by default/as a starting point PyPy's comp spaces will
be "open" ; as seen in Mozart with ports or whatever it must be hard
to restrict operations enough to ensure a proper sealing of a space
and in the case of Python, worse than hard ...

> 
> Best,
> --
> Grégoire
>