Frank Murphy

Hey @jorgecarleitao - we've integrated and tested the work on our side, and I'd like to start contributing back. Here are the changes: https://github.com/jorgecarleitao/arrow2/compare/main...WallarooLabs:arrow2:main Would you prefer this as one...

Work has been crazy, but I've finally gotten around to repackaging this. I believe it's a backwards-compatible new feature, not sure if I should slap the `feature` tag on it...

I'm interested in taking this on. So that I understand: the desired behavior for the mock `Stream` is the ability to dynamically insert `Item`s during the test? Otherwise you could...

Digging into this some more, it looks like both `Stream` and `Sink` have some runtime requirements that should also be enforced: - non-fused `Stream` objects have [undefined behavior](https://docs.rs/futures-core/0.3.17/futures_core/stream/trait.Stream.html#tymethod.poll_next) when `next`...

Ah, that makes sense. Thanks for the clarification. I have the `Stream` half ready. The `Sink` side is significantly more complicated, but I think I should be able to complete...

I'm puzzling out some additional behavior for waking, which is a bit more complex with a two-sided communication channel. In particular, the documentation for [`.poll()`](https://doc.rust-lang.org/stable/std/future/trait.Future.html) on the `Future` trait specifically...

Ok, one final question: is `.wait()` necessary? Couldn't it be defined directly in the test by spawning a task that does a `sleep` and then sequences the next operation via...

This might be a useful half measure. However, the full solution (translate werkzeug traceback so that the interactive debugger shows proper source, variables, etc) has been committed already (see 0b537235fb125f427de7ab4acbbe5f6f6f2a258d)....

No worries! This wasn't much work; I'm definitely glad to know early in the process. In the interim, I've started thinking about whether it makes more sense to add onto...