python ghcomp spaces in names of the outputs

I'm trying to use the ghPython node-in-code. My question is how to extract outputs that have spaces. For example box Corners component has spaces in the names of the output. (in reality I have problems with geco stuff but boxCorners is some common starting point)

| BoxCorners(*args, **kwargs) |
| Extract all 8 corners of a box.
| Input:
| box [Box] - Base box
| Returns:
| corner a [Point] - Corner at {x=min, y=min, z=min}
| corner b [Point] - Corner at {x=max, y=min, z=min}
| corner c [Point] - Corner at {x=max, y=max, z=min}
| corner d [Point] - Corner at {x=min, y=max, z=min}
| corner e [Point] - Corner at {x=min, y=min, z=max}
| corner f [Point] - Corner at {x=max, y=min, z=max}
| corner g [Point] - Corner at {x=max, y=max, z=max}
| corner h [Point] - Corner at {x=min, y=min, z=max}

import ghpythonlib.components as ghcomp

import ghpythonlib.parallel

a = ghcomp.BoxCorners(x).cornera

#a = ghcomp.BoxCorners(x).corner a

#a = ghcomp.BoxCorners(x).corner_a

None of the above works.

Thanks!

Replies to This Discussion

Permalink Reply by Anders Holden Deleuran on November 5, 2014 at 9:52am

Hi Dimitar, is there any reason why you are not getting the box corners using RhinoCommon? I suspect this would be easier and probably also faster if you have many boxes.

Permalink Reply by Dimitar Baldzhiev on November 5, 2014 at 10:02am

As I stated, the box component is just an example that represents the problem, I completely realize that calling boxCorners from ghcomp is retarded.

In reality I want to use ghcomp for external components that are not included in RhinoCommon (geco in particular, but this is not important).

Permalink Reply by Anders Holden Deleuran on November 5, 2014 at 10:05am

Ah I see, in that case, what Djordje said ;)

Permalink Reply by Giulio Piacentino on November 5, 2014 at 11:24am

Agreed that we should improve that naming!

What would be better in your opinion?

Thanks

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

Permalink Reply by Dimitar Baldzhiev on November 5, 2014 at 11:46am

in my opinion the first thing that came to my mind was either "_" or just remove all spaces...

maybe there will be conflicts ... I'm not sure.
On the other side I'm completely fine ,accessing the outputs as djordje said, the only problem is that I did not find any reference for that ...
In 2 sentences if you fix it -> great any way is good
if you don't fix it -> make djordje's answer more popular

Permalink Reply by Dimitar Baldzhiev on November 5, 2014 at 11:50am

I'm sorry but is there any official reference for ghcomp? I haven't found anything like that. Thanks

Permalink Reply by djordje on November 5, 2014 at 11:55am

Not that I know of any. The only help files on ghcomp are ghcomp function docstrings.

As for the naming outputs: in my humble opinion keeping the same Nicknames as the corresponding grasshopper components would be great.

Permalink Reply by Giulio Piacentino on November 6, 2014 at 8:34am

...so the scheme would be:

Name, then, if this contains illegal characters,
Nickname, then, if this contains illegal characters,
Somethings derived from Nickname + illegal things removed
If that is not enough (empty, etc), what we have today

Does it sound reasonable?

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

Permalink Reply by djordje on November 6, 2014 at 8:49am

Sounds ok.
I would still prefer the Nicknames as the option number one, but that's just my own opinion.

Permalink Reply by Giulio Piacentino on November 6, 2014 at 8:55am

Yes, I would like that too. It's for sure so that it would break very many scripts.

Permalink Reply by Giulio Piacentino on November 6, 2014 at 8:28am

Hi Dimitar

the module is open-source, and the type() function will tell you that the variable is a namedtuple. Here you can see the code that returns that.

The components module still needs some tidying up in the area of multi-threading (or we could remove that part and just have Grasshopper take care of that with a more case-by-case approach).

That being said, we should add documentation for it in the usual Grasshopper form and maybe with some specific blog posts.

Thanks for the hint,

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

Permalink Reply by djordje on November 5, 2014 at 10:04am

Hi Dimitar,

Most ghcomp function output parameter names still do not correspond to the actual grasshopper component outputs. I guess authors will fix this in the next few releases.

Until then, one can always access a certain output data by accessing an item from the tuple which ghcomp function returned (check the attached file, first ghpython component).

In case you still want to use the actual present output parameters names, you can print the returned tuple first. This will show you an actual output parameter names (the second ghpython component).

Attachments: