Grasshopper

algorithmic modeling for Rhino

What exactly is the structure of namespaces and variable scope for gh python components? I am aware that for importing, it is useful to use the sticky dictionary. I also notice that once instantiated in one component, the methods and properties of a custom python class are easily accessed from another component.

Furthermore, at times if a variable is defined in one component, it seems that other components have access to that variable (something I noticed today due to an error in my code).

Do all the components share a global namespace? Is that why the sticky should be used? 

If the components share a namespace and have access to each other's variables, perhaps there should be some best practices encouraged for encapsulation to avoid namespace pollution for using other peoples components. Also, if they share a namespace, what happens when a component is copied? Could the variables somehow get mixed up, if, for example, two different components define the same variable name in different ways?

Views: 1061

Replies to This Discussion

Hi Ben

I'll try to go through these questions one by one.

namespaces

as far as I know, there is no such a thing as a namespace entity in Python, so I believe you mean a .Net namespace. Or do you mean package? About .Net namespaces, Python just does not know about it so usually it pretends it's a package when looking into a .Net dll externally, and you just cannot define it internally. About packages, each component runs currently in an unnamed package, in an unnamed module (because there is no file association). This is similar to running code in the dynamic interpreter.

About variable scopes, each component runs in a separated language scope. Variable names should not conflict.

"at times if a variable is defined in one component, it seems that other components have access to that variable" This sounds really strange. I believe in what you say, but I hope I could repeat that? Something like this might happen if you write "from mymodule import *", and if in mymodule you have a variable a. That variable will be then taken over from there.

sticky is just a variable in an externally defined module, therefore it sticks in there... till that module is reloaded.

Is it reasonable?

- Giulio
_________________
giulio@mcneel.com

Sorry, I didn't mean namespaces as a specific class or object type, but perhaps I'm a bit confused on vocabulary. I understand a namespace to be, basically, an abstract space in which a certain set of names (variable names) are accessible. For example, packages, modules, and functions are all different types of namespaces. I understood scope to be the set of namespaces in which a particular variable name can be accessed. Maybe I just mean scope, and not namespace.

I'll try to reproduce the error I encountered. In the case I had defined, the variable name I was able to access across components was one that I had defined, and was not imported.

Thanks,

Ben

Yes, so I think we are talking about scopes. I hope the text above is useful.

There is maybe this one more thing to notice: if in a previous iteration you defined a variable, you will find it in the current iteration, too. This is because the engine is not taken down and reinitialized, but the code is reevaluated in the same context (root scope). This might be desputable has a positive effect on performance.

- Giulio
________________
giulio@mcneel.com

This means, when referring to scopes, that there is no way to declare "global" variables which would be accessible by any GHPython component in the GH definition?

See my reply here.

Edit: Seem that the link in the other thread is dead, as it referred to the old Rhino.Python forum. There is an example of how to use the sticky in the Rhino Python editor under Help -> Samples -> 13 sticky.


RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service