[Bf-committers] "Security" gets in the way

[Benjamin Tolputt]

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.