I just discovered a puzzling behavior that I’m having trouble understanding:
Here’s a trivial example of a Python component, it takes a list as input, then outputs the same list unmodified:
"""A test
Inputs:
jointLines: a list of lines
Output:
a: The same list
"""
__author__ = "dave"
a = jointLines
As expected, the path of the output matches the path of the input.
But then if I add a second input (with the default item access) to the Python component, it changes the path of the output, adding a second level. Huh?
However, if I make that second item use list access instead of item access, the path goes back to one level.
Hmm, bumping this in hopes of some sort of reply or insight. It’s hard to tell if no one knows what’s going on here, or if I’m just being dense (likely!) and the answer is obvious and not worth a reply.
Could this be a bug? For the record, it sure messed up one of my scripts, and it took me a long, long time to identify the culprit as simply adding a second input to my Python component.
Bumping this one last time, in case anyone can shed some light.
I’m just going on the assumption that this is a bug I need to work around: I can’t think of any reason that the structure of the output on a Python component should change when there is no change in the code itself.
For jointLines: list access there’s only one input and its data is treated as a list, which means that the script within the component executes exactly once and you’ll have to deal with the listed data internally.
x: item access now adds a second input and its data is treated individually. This means that the script runs a cycle for each item that you funnel in through x. Here it only cycles once, since your inputting nothing. Try to input a couple of things and the component will output how many cycles it ran.
x: list access now data of x is treated as list too, much like jointLines. Only one cycle is necessary and you’ll again deal with the listed data internally.
Thank you! I understand now: I’m triggering implicit Grasshopper cycles with my mismatched access types, so the extra “level” in the output is necessary keep separate the different possible results (IF I put multiple items into x).
In my original case, I just wanted to add a boolean input, to change how my code operated in a particular case, but doing so caused much havoc downstream, where I was expecting a particular tree structure. I understand now why it happened, but I admit I still wish there were an exception, if there really is only one item on that input. But I understand why that would probably be a bad idea.
