That’s just my two cents anyway. From my point of view the nodes are a little more complicated to setup but give flexibility with list structure (and don’t require any Python knowledge). I usually spring for a Python solution when it’s applicable but I think the specific list structure in this case might be too limiting.
1 Like
I think that is what is confusing. The way you explain it is that keys are just Index values. If that is the case then why have a separate node for them? Why not just use get item at index node? If they are not the same can you please give me a simple example on how this differs from get item at index?
@ricardoperucci I really appreciate the advise, but as Nick intuitively pointed out, I do not know Python, like many users on this site. Dynamo is my second step into the coding world. I hope to learn Python as I get better at Dynamo as my third step! Thanks!
2 Likes
Ok, thats nice to know. Thanks for sharing!
As Dimitar has explained, Keys don’t have to be indices. In fact, they usually aren’t, but if a list hasn’t had any Keys explicitly defined they default to what are essentially indices.
We don’t use GetItemAtIndex because it won’t work with this list structure. (At least I couldn’t get it to work.) This situation is better suited for a boolean mask. The only reason I used GetKeys was to show you that it was in fact getting the correct index of the correct sublist.
1 Like
Well that would have been very helpful. 
1 Like
I think my problem with not understanding keys then is the fact that you cant set them. There is no “Set Keys” node. Only a “Get Keys node”. So then how in the world can it possibly be any different than a Get item by Index? I mean it would be use ful for me to set, the keys, and then bind them to a value in a list, then sort the keys however I see fit, and then say, ok dynamo, now populate the new list with the original values that these keys belong to. But I cant do that…can I?
“Bound” keys (as you’re referring to them) only occur in a dictionary, where you can set the keys and their values explicitly. That’s what Dimitar is showing.
You don’t necessarily have to do that with Dynamo because we have nodes that allow you to specify the keys for a particular function - SortByKey and GroupByKey for example. Rather than setting key values for a list then performing a function based on those keys we can do it all at once. This means that we don’t have to define a dictionary and we aren’t limited to a single key value in our definition.
Yeah but if you sort by keys and they are just indicies, all you are doing is organizing by the indices which it already is. So this makes no sense.
Ok you lost me here. I am still not understanding at all 
maybe you can show me an example of what you are talking about?
The vast majority of the time Keys are not just the indices. That was only in your situation. You can use ANY value as a key.
Here is just a quick example showing Group and Sort using different parameter values.
Here I’m just sorting my duct elements by System Name then Grouping them. The final output is a list of the elements in each system (system shown as unique keys.)
I never “bound” my keys to the duct elements because the nodes are given the keys explicitly. That means I can also Group them by System Classification if I wanted to. I’m free to sort or group my elements by any characteristic as long as the initial lists are in the same order.
1 Like
Ohhhh ok, i did know you could extract any parameter out of the elements like that and sort by them. That could be really useful?