I have been thinking about this for a while, but, please accept my current opinion… with some excuses in advance.
“Reset script engine” was a bad decision to start with.
Rhino is a single ecosystem, and destroying any previous script engine will not work well for any other client of the previous engine (for example, GhPython, or any other plug-in). If you are at a point where the previous engine absolutely cannot work, then probably there is something that needs to be fixed beyond the scope of the engine.
An option is always to arrange the workflow so that a few calls to the standard Python reload() function will make all work again. There are cases where this is a little hard, but it’s still worth it.
The reason that destroying the previous engine is deleterious, is that any type managed by the previous engine will also be invalidated and replaced by new, diffferent types. However, the old ones may well be in use (for example, they could be Grasshopper components on the Grasshopper toolbar, or a panel, some Eto UI dialog, a background thread worker, …).
If we did compartmentalize the engines (I am not sure it is even possible, but let’s say that GH has one, Rhino has another) then they could not directly share types, modules, instances… for example with the sticky
variable.
So, I personally hope the “abuse” of Reset script engine will not be further perpetrated.
I am sorry for this slightly unwanted answer
Thanks,
Giulio
–
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com