Jason Wilkins wrote: > I think this is incorrect. The way PyPy is implemented presents a possible > solution. Depending on the maturity of PyPy this may be ways off, so I'm > just throwing this out to be considered. > > PyPy is a meta-circular interpreter, what that boils down to is the fact > that you can implement a python interpreter in the language with a small > amount of python code. >
I am not against an embedded Python interpreter at all. In fact, if you look at my recent comments I'm kind of leaning that way. It is not the "concept" I think will not work, but the "current PyPy implementation" which is unworkable. The current sandbox implementation of PyPy is a crude "all or nothing" mechanism. Which works well for running Python where you want the same permissions throughout the application. This is not the case in Blender where plugins need access to the network & file system but the scene itself does not. On the other hand, extracting a Python interpreter that only allows the calling of white-listed functions and limits the namespace to the data within the scene only (i.e. I cannot find restricted modules/data by browsing the namespace) from PyPy or another program is not a terrible idea. I believe that resistance to this idea is based around the very valid question of "Who is going to maintain this subset interpreter?". What happens when PyPy makes an incompatible change or the standard Python distro moves ahead of PyPy and there is a mismatch between the syntax semantic used in scripts & scene drivers? These are all valid concerns for a "graphics application project" without a huge pool of "Python engine coders" available. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
