What’s the best approach to building a script in a sense of structure and imports linkage?
Here’s what I mean: let’s say my program will use the ETO interface with which you can select Rhino objects, make different calculations, change different parameters with ETO widgets, and so on. As a result, a certain object should turn out, which will contain many variables and different data arrays. But this is not a Rhino object, i.e. not a surface, not a Mesh. It will just be a Python object with data (let’s call it XYZ Object). I also need that after closing the ETO window, this Python object remains in memory so that I can refer to it again if I re-run the ETO interface without having to reset all the parameters and recalculate everything again.
Let’s say I have a separate file with the ETO class, a separate file with the XYZ Object class, and a separate file with functions and calculation procedures for the XYZ Object.
My question is this: how is it better to build the overall structure?
For example, I can make the main running the ETO class file, and import the XYZ Object and all the functions into it. Then, what is the best way to do it: make the new XYZ Object Global, or as a variable of the ETO class (as in ETO Init: ~ self.this_XYZ_Object = import XYZ_Object)
My question may seem confusing, but I’m sure experienced programmers will understand what my problem is. Maybe there is a ready-made simple example with the use of ETO and several imports.
Thank you in advance.
Hi @monkelisha, probably the easiest would be to make a class from the XYZ object and when you create an instance from this class, make this instance global. If you need to retain it between different scriptruns, store the instance into scriptcontext.sticky or scriptcontext.doc.RuntimeData to remember it.
Thank You, clement, You are my best friend in the savannah
You advise to make XYZ global. For example, assuming that I have EtoModelessForm as main running script, I made these two options. In first XYZ is global, in the other it belongs to the ETO class.
What are pros and cons of these two approaches?
# FIRST -- EtoModelessForm with global XYZ
################################################################################
import Rhino, andAllOthers
from XYZ_obj_class import XYZ_obj
this_XYZ = XYZ_obj()
# SampleEtoModelessForm class
class SampleEtoModelessForm(forms.Form):
global this_XYZ
def __init__(self):
this_XYZ.Do_smth()
################################################################################
# SECOND -- EtoModelessForm with local XYZ
################################################################################
import Rhino, andAllOthers
from XYZ_obj_class import XYZ_obj
# SampleEtoModelessForm class
class SampleEtoModelessForm(forms.Form):
def __init__(self):
self.this_XYZ = XYZ_obj()
self.this_XYZ.Do_smth()
Hi @monkelisha, i think both would work, it is your own preference which to prefer. I prefer below where i keep the classes in the same file, so i can compile scripts as plugins since modules are not supported:
# define classes here
# ....
# have one main routine
def MyMainRoutine()
global form, this_XYZ
# make (global) instances of the classes
form = SampleModelessForm(forms.Form)
this_XYZ = XYZ_obj()
Thank You, clement,
thats useful info for me. Now I can keep on mooving forward.
You said, that modules are not supported… Does this mean that if I decide to use, for example, Numpy, then I will no longer be able to make a separate plugin, but my program can only be in the form of a script?
Hi @monkelisha, i guess Numpy is not supported in IronPython 2.7 which Rhino uses atm. This may change when you use CPython.
My comment about using modules (py files), scripts using this imports will not work when compiled using the RhinoScriptCompiler or Yak. However if you do not plan to compile, you should not worry about it as the scripts still can be executed.
