General Python Questions

Replies to This Discussion

Permalink Reply by Giulio Piacentino on December 11, 2013 at 3:09pm

Hi Gui,

I'll try to answer your questions one by one. Some of these questions refer to ghPython itself, some are Python questions and some are Grasshopper questions. So, you are asking here at the right spot :)

1. Is scriptcontext used to define docspace only?
   
   scriptcontext is not used only for that. It contains quite some few variables that allow to do different things. For example, there's the sticky dictionary, useful to store temporary information and bring it also across components or over to the _EditPythonScript editor. It is a real module and you can find it in the folder containing also the rhinoscript library.
   
   
2. Not sure how to use these: [...] AddReference('Grasshopper')
   
   There is no longer any need to use this call in the last release of GhPython, as the component automatically adds a reference to the Grasshopper library (grasshopper.dll) for convenience. As it might already be clear to you, Python itself does not know about Grasshopper
   
   
3. How is the gh kernel used in relationship to rhinoscript?
   
   Not in any specific way. They are two different libraries. The Grasshopper kernel does not know about the ghdoc document, so -- if you ever need to use it -- you can use the rs.coerceXXX() functions to get the geometry from rhinoscript Guids.
   
   
4. >>from Rhino import Geometry as make
   
   Please don't import modules with very-different-looking variable names (aliases). Other people will have more trouble following.
   
   
5. Where can I find documentation on ghenv?
   
   Sorry, there is no more documentation than what you can see with autocompletion. However, there is also nothing else there, other than that! We do not encourage modification of Grasshopper behavior via this variable. You can see its sourcecode here:
   https://github.com/mcneel/ghpython/blob/master/Component/PythonEnvi...
   The most important information, as you already discovered, is Component, which returns a GH_Component instance (a ZuiPythonComponent instance, to be precise -- but this might change in the future). GH_Component is defined in the Grasshopper SDK.
   
   
6. (Paraphrasing from your comment) Why are these calls doing the same:
       a = rs.AddPoint(x,y,0)              #rhinoscript
       b = ghdoc.Objects.AddPoint(x,y,0)   #rhinoscript? access through ghdoc? how is this different?
       c = sc.doc.Objects.AddPoint(x,y,0)  #only some of the rhinoscript methods available
   
   These calls are not doing the same. I understand how this might seem difficult, as this is the result of normal OO (object-oriented) design, where you might get reach to the same (or similar) objects through different calls.
   Now, rs up there is rhinoscriptsyntax module up there.
   ghdoc is a variable (similar to ghenv) that contains a reference to the invisible Grasshopper document. The document (both Rhino and Grasshopper ones) have an object table available through the Objects attribute. So,
   sc (the scriptcontext module) has a variable (doc) which gives you whichever document is current. In GhPython, this is by default ghdoc. In Rhino (the _EditPythonScript editor) this is by default Rhino.RhinoDoc.ActiveDoc. This is the place where rhinoscript functions add geometry. Whoever called AddPoint(x,y,0) that way, bypassed standard methods and added geometry through the same call that eventually rhinoscriptsyntax uses.
   
       d = Rhino.Geometry.Point3d(x,y,0)      #rhinocommon
       #e is exactly the same as d, just with another shortcut. Dont do this if you can.
   
   d invokes the RhinoCommon constructor for Point3d. This returns a 3D point.
   Use type(var) to get the type of a variable. Other methods exists for other reason (this is IronPython), but please stick to this one unless you know why you should be doing differently.
   
   If the first three calls are successful, a, b, c will contain Guids that refer to objects in documents. d will be the RhinoCommon geometric point itself. This has advantages and disadvantage: objects in the document have also attributes like color, linetype, etc, while geometry is completely "bare-bone".
   
   
7. >>got bake figured out on component below.
   
   Nice, so you are putting these concepts into practice.
   
   

I hope this rather long answer was helpful.
Thanks, kind regards,

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by Gui Talarico on December 13, 2013 at 11:40am

Giulio - 

Thank you so much for the detailed response. It was incredibly helpful.

I played around with the sc.sticky, seems helpful.

If you don't mind, I have just a few other simple questions.

1. Regarding documentation, let me see if I understand this:

rc > RhinoCommon SDK Help File

rs > Rhino IronPython + Rhinoscript (Programmer's References)

gh > Grasshopper SDK Help File

ghenv > source code of ghpython only

2. Regarding the ghdoc and ghenv variables, where are the originally defined?

3. For making geometry, what would be the preferred/recommended method?

rs/rc/ or the latest ghcomp? Depends on the use?

Thanks again, 

Gui

Permalink Reply by Giulio Piacentino on December 13, 2013 at 1:35pm

1. Yes, so, documentation:

Rhino -> RhinoCommon SDK Help File

rhinoscriptsyntax -> _EditPythonScript file Help (or F1 in editor)

Python -> docs.python.org

Grasshopper -> Grasshopper SDK help file

2. As you say, ghdoc/ghenv are just two variables. The first one contains an instance of GrasshopperDocument, the second one of PythonEnvironment. They list a series of RhinoCommon/Grasshopper/Python references, that might occasionally be useful. They are not needed to create geometry, but just to address special topics that might occasionally be useful. In fact, GrasshopperDocument does the same as RhinoDoc with ObjectTable, while ghenv really does specific things like connecting with Intellisense, providing the Python interpreter instance, or the local scope (the object that represents the executing place of the script).

3. All methods that work for you are "the best" ones. To start I really suggest to use GhPython with rhinoscriptsyntax, which is also the most concise way. Later, RhinoCommon might work, too. ghcomp is useful especially to use components that would otherwise not be accessible, like Delauney or Convex Hull.

I hope this helps,

Giulio

--

Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by Gui Talarico on December 16, 2013 at 4:34pm

Thanks again!

Permalink Reply by asyimut on August 25, 2017 at 3:00am

Hello! 

Is there a way to create a copy of a GH list input on the python component, so I can update it every loop.. So the initial list is from gh but I want to change items in it every loop and send it back to the next loop in its changed condition. Hope its clear! attached a simple example of my question...

URGENT! 

asyimut

Attachments:

• copyList_updateGHlist.gh, 7 KB

Permalink Reply by Anders Holden Deleuran on August 25, 2017 at 3:38am

Sounds like you might be looking to make a persistent variable (remember the old phantoms :D).

Permalink Reply by asyimut on August 25, 2017 at 6:27am

HAH definitely yes I remember. I went through all the threads you referenced but still so confused with the gh's list input to python as GLOBAL VARIABLES.. is there really a way to replace the items coming from the gh list eventhough the operations are referring back to the same list. so I made another caps for my intention. 

My original code works with a timer, and every step I make the change in the list (an input from gh) and I want to continue the same operation on the changed list. they have the same name ofc. ghosts need to be buusted

All the best from Graz!!

Attachments:

• stickiness.jpg, 520 KB

Permalink Reply by Anders Holden Deleuran on August 28, 2017 at 5:18am

I'm afraid I don't quite understand the issue(s). There seem to be several things going on at once here. It would help if you could break the logic into more explicit steps, and/or, provide a minimal example file that demonstrates (with comments/scribbles etc) what you're trying to achieve. That said, if the problem is that your variable b in the Python component keeps changing on each update. That is because you're not setting a random seed, meaning that the randint() function will return a new random integer at each call. Also, I suspect you still might be in need of a persistent variable (that is, a variable within the scope of the GHPython that isn't re-instantiated each time the component updates, enabling you to iteratively operate on data ala Kangaroo). That probably didn't help much, apologies :)

Permalink Reply by Anders Holden Deleuran on August 28, 2017 at 5:51am

Perhaps the attached file will better demonstrate what I'm talking about. That is:

1) Grabbing the data from an input list and storing this in a persistent variable.

2) Updating this data when you click a button.

3) Outputting this data to Grasshopper.

Attachments:

• 170828_GHPython_PersistentVariableList_NoSticky.gh, 7 KB