List.Combine BUG

1

I have a strange bug from List.Combine that I cannot replicate for simpler definition.

but here is an image where i show that substituting List.Combine by a small script does the job while List.Combine fails giving a null value without apparent reason:

forum_bug
forum_bug.jpg1376×1080 559 KB

and here the script:

data1 = IN[0]
data2 = IN[1]

couples = []

for i in range(0,len(data1)):
	couple = [data1[i], data2[i]]
	couples.append(couple)

OUT = couples
2

Hi,
maybe ‘function.apply’ is working :smiley: give a try

3

Wouldn’t a normal List.Join + List.Transpose work the same way?

4

Good to know there are other ways, thanks for that :+1:

But I wasn’t really looking for it as the python script does the job I wanted.

My problem is understanding why the List.Combine doesn’t work as it should, am I doing something wrong or Dynamo is flawed?

I am using Dynamo Core in Alias 2019

5

Yeah, it’s akways better to use python. Sometimes ppl ask on the forum how to do sth and they tell you use built-in nodes :smiley: Your example is just perfect. Nothing is so simply, especially when you are working on bigger data sets and floats. It’s like casting integer to string and getting decimals :frowning:
Just curious, could you try adding ‘object to string’ before combine? Or round up these values?

6

Not really, specifically when you start to look into how stuff scales and is maintained. One graph, you’ll never want to reuse, and which can live on forever, sure. But imagine having to update every python node in every graph you’ve ever written due to a breaking syntax change. Had you used an OOTB node you’d already be done, as Dynamo would handle such a change automatically. Had you used a custom node, you’d have to make the change once, save the node, and all the graphs would be updated.

2 Likes
7

seems like this would be good to report on the github issues page.

1 Like