zip

You've got two (or three, or four) lists that belong together - a list of prompts and a list of seeds, where prompt number one goes with seed number one. DataListZip stitches them into a single list where each item is a bundle of the corresponding elements. It's Python's zip() in node form, and it's the tool for turning parallel lists into paired data.

Inputs: list1 and list2 (both required, any type), plus optional list3 and list4. Output: one list where each item is itself a list - [item1_from_list1, item1_from_list2, …], then [item2_from_list1, item2_from_list2, …], and so on.

How it works

Mechanically it's zip(*lists), with each zip-tuple converted to a list. The one rule to internalize: the output stops at the shortest input list. If list1 has 5 items and list2 has 3, you get 3 pairs - the extras in list1 are dropped. That's standard zip behavior, and it's usually what you want (it's how you prevent misaligned data), but it can silently eat items if your lists got out of sync upstream. Count your lists with DataListLength first if you suspect a mismatch.

The output is a list of lists, so each bundle flows downstream as one item - which is where the pack's DataListListCreate comes back around: zip builds your pairs programmatically, ListCreate builds them by hand.

Why you'd use it

This is the backbone of any parameter-sweep or paired-iteration workflow. Keep prompts in one list, CFG values in another, zip them, and now each "row" travels together through your pipeline. It also plays nicely with DataListRange - range gives you the index sequence, zip pairs it with a matching list of values. If you've been hand-maintaining parallel lists and praying they stay aligned, this is the node that ends that anxiety.

Installing it

Part of StableLlama's Basic data handling pack - pure Python, zero dependencies, no models:

cd ComfyUI/custom_nodes
git clone https://github.com/StableLlama/ComfyUI-basic_data_handling

Restart ComfyUI, or search "Basic data handling" in ComfyUI Manager. No requirements.txt drama, since the pack ships dependency-free.

Common issues

The shortest-list truncation is the thing to watch - if your output is mysteriously shorter than expected, one of the inputs is short, not the node being broken. And because the output is a list of lists, downstream nodes see each sub-list as a single item; if a node expected a flat list of values, that's the nested structure biting you, and DataListExtend-style flattening (or the pack's ListCreate-to-LIST converters) is the way out.