> That said, there's no harm in a quick discussion of other options, but if the scope/time-scale starts to grow then I'd far rather just get this PR merged first. So...

TBH, I thought it had already been merged.

> In which case I'm not sure you'd still want to have biggus.ndarrays(), as it would just be a call to biggus.engine.ndarrays()

There is no harm if ndarrays gets called frequently and the user doesn't care which engine is doing the work - it is just a simple interface function as you say.

>  And then when more control is needed, one could explicitly supply arrays to an engine instead. For example: ```results = engine.ndarrays(my_derived_array, my_other_derived_array, ...)```

This feels very natural - so much so that I had to check that that wasn't already the case.

So with all of this said - I'm happy to review this PR as it is if you'd like, alternatively implementing the Engine.ndarrays interface would be an appealing step which *could* be done here.

Your call.