I just jumped to Dynamo 2.0.0 today and I noticed a difference between Dynamo 1.x and Dynamo 2.x.
The Node List.ContainsItem (in 1.x) and List.Contains (in 2.x) perform the same action on the lists, but I keep getting different results. In the new version 2.x the Node doesn´t return true on the Index1.
Am I missing something here?
Hmm very curious, the only difference I can see is that the object type have changed from 1.3.x to 2.0 (from System.Int32 to System.Int64).
Is there any alternative to go around this issue? It must be a general issue, which affects a lot of scripts out there?
I noticed this issue when trying to adapt an old script from 1.3.x to 2.0 and it simply didn’t work because of this List.Contain “step”.
@Vikram_Subbaiah thank you for your solution!
Do you know if this is the Node “normal” Behaviour, or is this solution a “workaround”? It seems that this Node is more complicated to use in the new version of Dynamo, than in previous ones.
It’s not a work around. This is the way lacing works in 2.0
Also, this altered behavior isn’t specific to just this node.
I read the Post related with this Dynamo new version. If the “Auto” lacing match the single items with lists as the “Shortest” behavior did in previous releases, why should we need to specify the lvl of the items input inside of the Node? If it is supposed to work out like previous versions, one shouldn’t need to specify any levels (just thinking out loud)
I am just trying to understand the change here, thank you again @Vikram_Subbaiah
What’s a bit ambiguous about this is that at a certain point in ver 1.x, the “default” lacing option was made “smarter” and upgraded to act the same way as Auto in 2.0 while still looking the same way as shortest lacing. Not sure if there was enough publicity about this change:
Now it seems like 1.3 nodes are incorrectly being upgraded to the wrong lacing.
Yes. When I was upgrading my scripts to the 2.0 Version, the “Auto” lacing was not behaving as the “shortest” lacing in 1.x, hence different or wrong results came up.
As I am fairly new to Dynamo I will need to check this differences by myself, perhaps making some tests with Lists.
If there is more documentation about the differences on this lacing theme, please let me know. As far as I know, Lacing needs to be fully understood in order to make a successful script.
Thank you very much for the article @Dimitar_Venkov
So this is the conclusion that I came up with…
I tried to sketch the logic behind the Lacing, but I am not sure if its correct. Either I didn’t understand the lacing in 1.X Dynamo Version (I was able to make some Scripts work though 
) or I just forgot my brain while coming back from holidays.
Please bear with me 
Regarding the Lacing on Node List.Contains :
“Shortest” V1.X behaves as “Auto” with @Lvl in V2.0
Why is “Auto” returning only one item as false?
I think single is the operative word here 
Seems like AUTO really considers the input as an item, not items
You’re not alone. However, your sketch of the logic seems quite accurate to me.
I’d initially assumed that Auto was the most appropriate of the three original lacing options for a particular node.
However, I was made to understand here, a few months ago, that not only was AUTO lacing something else, but that the way lacing has worked prior to 2.0 hasn’t exactly been accurate.
Now that means that the Scripts migration from older versions to 2.0 need to be reviewed and adapted carefully as the “Shortest” lacing will be automatically replaced with “Auto” lacing.
Thanks again for your very helpful Inputs.
As a conclusion, I leave here some snapshots of the Dynamo 2.0 Lacing explanation that I made for myself. Maybe this could be useful for someone else.
Again, I don’t know if its totally correct or even if makes sense to some of you. If someone of you experts sees that something doesn’t make ANY sense at all, please let me know. I am here to learn.
Credits to @Vikram_Subbaiah and @Dimitar_Venkov that guided me through this subject.
post Edit:
I just don’t know why this Node continues to return different booleans depending on the data type.
Does this make sense?
I don’t know either! But discussing a bit we think it might be because strings are actually Ienumerable and so are may be converted to lists in the DS vm.
you might try wrapping your integers with lists like this
[[4],[5],[6]]
Took a closer look. One thing that hasn’t been pointed out, is that the “old” node worked on a singleton (“var”) type of input, where as the “new” node’s item input is of variable rank (“var…”). That will have a huge effect on how the function is mapped and the particular change doesn’t make much sense for this node’s use case. The easiest way to restore the old functionality is to leave the lacing as auto and set the level of the “item” input to @L1:
You actually get similar results if similar individual elements in the lists correspond, both for numbers and strings.
There is an issue, but don’t think it’s a data type issue 
Below are examples…
