horace grant wrote: > http://www.philhassey.com/blog/tinypy-ideas/ > > """ > Embed tinypy > > * Objective: sandbox tinypy and then (as in lunatic python) build > a python module that uses tinypy for safe execution of “unknown” code > """ >
Not a bad idea, though not standard Python. Honestly, if the core Blender developers are willing to relax their "no non-standard Python" stance, it could possibly work. It WOULD require every object in the scene having two "representations", the standard Python object & a TinyPy version. So there will be a hit in memory & code complexity... but it is not "bad by design", which is a step up. My claims about Python being unusable have been based on the fact that Blender devs have stated opposition to using anything but standard Python with standard Python API's. PyPy somewhat fit this bill (for future implementation) as it's stated goal is 1-to-1 compatibility with CPython. Unless this limitation on what Python can be used is removed - my position is still the same. I can actually see their reason behind this too. After all, who is going to fix a bug when a snippet of code syntax/semantics works in an import/export plugin bt fails in the driver due to a TinyPy bug? Whenever Python upgrades, they'd need to wait for TinyPy to catch up on the changes. And heaven forbid the situation where the TinyPy developers throw in the towel and the maintenance (and upgrades) are left to the Blender team. There is a very valid reason for wanting all the scripting to use a standard library supported by a mature, large, and established community. > it's just an idea at the moment and not implemented but this sounds > interesting. :) tinypy could be used for drivers in the long term. > Exactly, the only thing TinyPy would need access to is other elements in the scene. The same could be said of ANY other embedded language solution as well, but there is a large benefit to keeping the same language syntax & semantics throughout. > in the short to mid term there doesn't seem to be an easy and secure > solution but in the long term all the "this is impossible with python" > seems to be wrong to me. to me it looks like in 2-3 years the whole > situation will look different (pypy, tinypy,...) and there will be > feasible solutions. > Mate, the problem is present now. We need to look at solutions *now* not at some years distant time in the future. Can you imagine the lack of advancement in Blender if developers thought "It's too hard now, someone else will have implemented a library we can use in two years time, then we'll look at it"? Advancement comes from those unsatisfied with the status quo and do something about it in the present. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
