Brian McFee

@ejhumphrey alternately, we maintain two implementations of mux, and use a runtime version check to determine which one to import. I hate the idea of maintaining two copies of the...

> well what if we first write a subpackage as a dependency called byepy2 that throws a deprecation warning for python2.7 any time it's imported? Seems overkill to have a...

Agreed; still gotta make sure this is all kosher wrt mixing async and generators in 3.4/3.5 though.

> Yeah; I think the 3.4/3.5/3.6 asyncio changers/messiness is actually where > our problems will lie. Been doing some reading about this. I think it's only a problem if we...

(update after scipy2017) An alternative might be to re-implement mux using [concurrent futures](https://docs.python.org/3/library/concurrent.futures.html). Even within a single python process, we can still get concurrency over the individual streams using the...

I had a bit of a think on this last night, now that the dust has settled on the refactor. As noted above, async mux only makes sense for stochastic/shuffled...

This all sounds great. The only other thing I'd prioritize above this is finishing up the article we mostly wrote, and I think is only wanting for some literature review...

Circling back: this could be much cleaner after we drop 2.7 #149 so that we can use the `raise from ...` syntax for exception chaining.

First, thanks for implementing this! I haven't spent much time with pytorch yet, but the above all makes sense from what I've read in the api docs. The index thing...

> On the downside, I found that using the pescador buffered_zmq is a lot slower than random sampling using the pytorch samplers. This I suspect is due more to the...