Hi Martijn, Chris, On Mon, Jul 28, 2008 at 11:09 +0200, Martijn Faassen wrote:

On Fri, Jul 25, 2008 at 8:46 PM, holger krekel <holger@merlinux.eu> wrote: [description of how this might work]

Cool, thanks for the description.

you are welcome!

Just for context, the Python 2.5 porting project is happening this summer as part of the google summer of code. We're talking about a timeline of weeks here. We're also talking about an important feature used by *many* for the last 7 or 8 years or so in a stable release of Zope 2. There's lots of code floating around that uses this feature. The new code would need to run on the platforms that Zope 2 runs on.

If I were to write a new version of sandboxed Python in a new framework, this sounds potentially useful. I know Chris is interested in such technology aside from the interest from the Zope 2 perspective. But from the current Zope 2 perspective, this looks like a rather long-term development path with a lot of bugs to work out.

Indeed, what i described is not likely to come to happen in the next weeks.

The pay-off would be a more secure version of Python Script in Zope 2 that is hopefully more easy to port to new Python versions. That would be nice, but the risks involved in this project are also rather huge, and unfortunately I don't think the pay-off is huge enough to warrant a lot of investment in time by (rare) Zope 2 hackers. I'd be happy if one of them proved me wrong, but it doesn't seem to be a good idea to let the new Python 2.5 compatible version of Zope 2 be dependent on unfinished PyPy technology....

Makes sense to me as it stands. I am sure that when the time comes we'll find good use uses for a robust virtualized embeddable Python Interpreter. Having people or parties already asking for it (or better yet, investing into it :-) would certainly accelerate it. cheers, holger -- collaborative expert contracting: http://merlinux.eu PyPy Python/Compiler tool chain: http://codespeak.net/pypy pylib py.test/greenlets/svn APIs: http://pylib.org