Multiple stims in API requests about pliers HOT 3 CLOSED

Yes, good idea. Tweaking the Graph API is actually the straightforward part (we can add a batch argument in the Graph initializer, which, when True, passes all Stims to each node in the graph as a single list, and when False, loops over Stims). The real question is how to handle looping in the Transformer and Stim classes. I can think of two reasonable approaches:

A) Create an IterableTransformer class that can be mixed into any Transformer, and simply overrides the base Transformer class's transform method to loop over elements and return the resulting dict as a list (or, with an optional merge_results argument, perhaps a merged DF). Transformers that require custom handling of batch requests (which is probably all of the API Extractors), will need to be updated on a case-by-case basis.

B) In the base Transformer, add an _iterate method or some such, which gets called from the base Transformer class's transform method in the event that the passed stim argument is a list or tuple. Then the logic is roughly the same as in (A), in that the base class's method can just loop over all elements one at a time, whereas individual Transformers can override _iterate and do whatever they need to there.

The main benefit of (A) is it avoids imposing constraints on how each API Transformer implements the handling of lists (no need to break up code into multiple methods, which could get messy in some cases). The benefit of (B) is it avoids complicating the hierarchy and doesn't require most Transformers to inherit from an extra class. I guess I lean towards (B) slightly, on the assumption that the vast majority of Transformers will never need to do anything other than naive looping. What do you think?

from pliers.

I would lean towards (B) more as well, as I generally side with a simpler hierarchy. I would also assume that every Transformer will fall into one of two (naive looping, grouping into call) types.

from pliers.

Addressed in #69.

from pliers.