[cascade/executor] improve generator handling

[tmi]

(expected) behavior change:

situation 1): graph node with a single child and generator callable
before -- crash with "generator cant be pickled"
after -- call iter once, crash if not empty afterwards with "more outputs than declared", otherwise return that single result

situation 2): graph node with a single child and callable returning Iterable non-Generator
before -- return the whole Iterable as the single retval
after -- unchanged

situation 3): graph node with N children and generator callable
before -- return ith generator element to ith child, crash if len(generator) != len(children)
after -- unchanged

situation 4): graph node with N children and callable returning Iterable non-Generator
before -- return ith iterator element to ith child, crash if len(generator) != len(children)
after -- crash

so we trade one bug for another. However, I believe situation 2) is also a bug, so we should strictly discourage Iterable non-Generators (like lists or strings) as return type to provide for multiple children

alternative is we set a strong contract between fluent and cascade for whether the output is expected to be iterated or not, and we only do type checking at runtime when having to. Happy with that as well

[jinmannwong]

However, I believe situation 2) is also a bug, so we should strictly discourage Iterable non-Generators (like lists or strings) as return type to provide for multiple children

I'm not sure I understand why this is a bug? What's wrong with having a graph node with a single child that returns a string?

I think the trade off between 1 and 4 is ok, as in fluent we don't create multiple outputs unless the return is a generator. I also don't mind the alternative of having a stronger contract between cascade and fluent.

[tmi]

I'm not sure I understand why this is a bug? What's wrong with having a graph node with a single child that returns a string?

I did not explain enough, I meant like you have a task that returns a list, so for two children you return [r1, r2], but for one children you return [r1]. This is impossible to handle correctly relying only on typing information or on graph structure information, we would need correct schema or some flag "extract from result". Oh and strings are complete weirdos, because string[0] is still a string, unlike list[0]. Imagine we had a logic like "extract n-th element as long as the type is iterable", thats infinite loop for strings :) (or for self-referential lists like l = []; l.append(l))

So I'd say "returing a non-generator iterable and expecting cascade to extract values over children" is a bug on the side of the job author :), for two reasons: 1/ difficult to handle by cascade 2/ you don't gain any speed or memory advantage of eager evaluation. The 1/ is a weak argument, of course having correct schema is the best long term fix here. But 2/ is imo more meaningful -- I'd always try to redesign the callable to not materialize the whole list

[jinmannwong]

So I'd say "returing a non-generator iterable and expecting cascade to extract values over children" is a bug on the side of the job author :), for two reasons: 1/ difficult to handle by cascade 2/ you don't gain any speed or memory advantage of eager evaluation. The 1/ is a weak argument, of course having correct schema is the best long term fix here. But 2/ is imo more meaningful -- I'd always try to redesign the callable to not materialize the whole list

Ah, ok, I understand now.