_.toArray

_.toArray takes anything iterable and returns a real, plain Python list. A tuple becomes a list. A set becomes a list. A dict becomes a list of its values (this is underscore behavior - iteration over a dict yields values, not keys). Even a generator, if one ever wanders into your graph, gets drained into a proper list. The description calls it "useful for transmuting the arguments object," which is programmer-speak for "normalize weird iterables into something every other node can handle."

In ComfyUI terms, it's the type-safety valve for the ovum/underscore family. These nodes accept *-typed inputs and a lot of them hand back *-typed outputs, so by the time data has been through a chain, the graph may honestly not know whether it's holding a list, a tuple, or something else. _.toArray is the node that pins it down: out comes a LIST, properly typed, so a strict downstream consumer can't complain about a tuple in list's clothing.

Inputs and output

• list_or_dict (*) - the collection to normalize. Lists pass through (as a copy, not the same object - the wrapper deep-copies), dicts become lists of their values, sets and tuples become lists.

Output is a LIST - one of the few typed outputs in the family, and the reason to prefer this over a blind cast when you need a guaranteed list on the wire.

The family chain behavior applies: feed a _.CHAIN in as the primary input and it keeps the chain going, returning a chain rather than a plain list - unwrap with _.value. Which can trip you up, because "toArray" sounds like a terminal "give me the final list" step. If you're chaining and your "final" output is a chain object, you've hit that switch; add _.value after it.

Why you'd reach for it

Any time a downstream node rejects your data with a "list expected" error and you're not sure what shape the upstream actually produced. Slice operations, set arithmetic, and dict-value extractions elsewhere in the underscore family all return objects that don't always declare themselves as lists; a single _.toArray between them and the strict node clears it up.

Install

# via ComfyUI Manager: search "comfy-ovum"
cd ComfyUI/custom_nodes
git clone https://github.com/sfinktah/comfy-ovum
# restart ComfyUI

No model downloads; pure Python, deps (aiohttp, pillow, numpy, requests, etc.) via Manager, underscore3 bundled in the repo. The author's README flags the underscore family as work in progress - for a pure normalization node the risk is low, but if your "list" still misbehaves downstream, check whether you actually fed it a dict (values only, keys dropped) or a _.CHAIN (you get a chain back, not a list).