Output names that cannot be variable names

Replies to This Discussion

Permalink Reply by Giulio Piacentino on November 26, 2013 at 5:20am

Hi Marcus

can you explain what you are trying to do?
Are you trying to have spaces, hyphens or operators in output names? Or something else?

Thanks,

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

Permalink Reply by Giulio Piacentino on November 26, 2013 at 10:47am

I see what you are willing to do here, Marcus.

Well, the ghPython component right now uses the local scope to pick up outputs. So you could make this work by setting the locals() dictionary with special variable names, like '1'. There's an example attached.

However, I am not sure if this will work in next iterations of the component or of IronPython, the interpreter that we use to execute Python. In the next release of the component, I will add a new attribute in ghenv -- the DataAccessManager, with which you could set outputs a little more easily.

This, in turn, will work as long as there are no breaking changes in the Grasshopper SDK. Well, you see, when one departs a little from the standard, there might be some price to pay.

I hope this helps,

Giulio
--

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

Attachments:

• pyItem2.gh, 12 KB

Permalink Reply by Giulio Piacentino on November 26, 2013 at 1:04pm

Of course, internally there has to be some way to set the relationship so this is the intended way to use the component, and is no syntactic sugar. The ghPython component really picks up names from the local scope*. There is nothing bad about that, except that, as you noticed, it is possible to give outputs no name, invalid names, or repeated names, that would not really be useful. Just because something is possible, it does not have to make sense in all cases.

However, the Grasshopper SDK has several AddDataXXX() methods, that could be used instead for these cases, and could set up based on order. They are less straightforward to use, so, right now, they are unreacheable from the ghPython component, just like in all other scripting components.

Following your wish, I've added code to provide them, as I was mentioning before, in the next release, when the IGH_DataAccess object will be an additional attribute of ghenv.

Giulio
--

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

(* the exact mechanism might change in the future, but the assumption that a variable assigns to the output of the same name will be kept intact)

Permalink Reply by Giulio Piacentino on November 26, 2013 at 2:24pm

It was great! One tiny suggestion for next time, maybe, is to provide the problem that you are trying to solve in the question. I was not smart enough to understand for sure what you were trying to accomplish.

We had considered this very issue when we talked about development at the beginning of this component. Steve suggested this method and it was chosen. Nobody complained about it till now.

In the next release there will be a way to access that argument of the SolveInstance method in IGH_Component objects, so you can do this, too :)

Giulio
--

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