split (LIST)

The LIST-flavored twin of "split (data list)": same re.split() engine, but the pieces come back as one Python list variable instead of fanning out into individual items. When you want to hold the split result together - count the pieces, index into them, iterate over them as a unit, or pass the whole collection to a node that takes a LIST - this is the one. When you want each piece flowing into its own per-item slot downstream, grab the data-list version.

It's a small distinction that determines whole workflows. The pack's own README frames it as: data list = "process each item individually," LIST = "work with the collection as a complete unit." This node is unambiguously the latter. Split a CSV-style string on \s*,\s* and you get ["col1", "col2", "col3"] as a single object you can inspect, reorder, or convert to a SET.

How it works

One call to re.split(pattern, string). The behaviors that matter are the same as the data-list variant because it's the same function:

• Separators are dropped unless you capture them - wrapping the pattern in (...) keeps the separators in the result.
• Empty pieces from leading/trailing separators are kept: ",a,".split(r",") → ["", "a", ""].
• Because it's regex, the split point can be structured - splitting on (\d+) chops the string apart at every number.

The only difference from its sibling is the output type: here it's LIST, and there's no OUTPUT_IS_LIST flag, so downstream receives one list object rather than a fanned-out series.

Inputs and output

• string - text to split.
• pattern - the regex separator.

Output is a single LIST. No match means a one-element list containing the original string - that's expected, not an error.

Installing it

Ships in Basic data handling by StableLlama:

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

Restart, or install via ComfyUI Manager (search "Basic data handling"). Zero dependencies and no model downloads - stdlib-only, so it can't conflict with your other nodes.

Gotchas

• It's the LIST one. The single most common mistake is grabbing this when your downstream node expects individual items - you'll get one purple list object and a confusing type error. Check the display name ("split (LIST)") before wiring.
• Empty strings in the result are normal; filter them before feeding string-only consumers.
• Greedy separator patterns can eat more than you intended. Quick test on a scratch node pays for itself.