Support async use-cases

[non-Jedi]

Since we're supporting both python2 and python3, our async options are very limited. I think we have to either use gevent, use threading, or maybe we can use something from the twisted stack?

Personally, I'd really like to just drop support for python2 (it is the way the ecosystem is moving anyway), and use either the 3.4 syntax of @asyncio.coroutine and yield from or 3.5+ of async def and await. It would give us much more semantic code. Maybe the right answer is just a community-maintained async fork for python 3.4+.

Issue created to separate out discussion from #126.

[pik]

Absolutely not. Async will make the REPL experience significantly worse, python3 async API has been constantly changing, python2 has no async equivalent to the python3 in the stdlib (you'd have to use gevent or something) - finally again, this is totally unnecessary - I use the sdk at the moment to run synchronous tests / REPL and there is no cause for extra complexity.

If you are building something that needs extra complexity, you should wrap the sdk in whatever async / threading paradigm that you need.

[non-Jedi]

You're right. I hadn't fully considered the implications of making it async. It would make usage of the sdk more difficult for >50% of use-cases. As an aside, I believe that python3's async api hasn't changed since 3.5, and it's considered stable in 3.6, but that's beside the point.

The reason I opened this issue is that it would be nice to include a lot of the architecture needed for building an event-driven app in one place. One of the more obvious examples would be queuing requests as I believe is done in the JS sdk. Maybe there just needs to be another package wrapping this one providing that async architecture; I don't know.

At the very least, to support async use-cases, we need to get rid of the while loop inside of _send or make it explicit in the documentation that the _send method must be overridden to support async.

[pik]

At the very least, to support async use-cases, we need to get rid of the while loop inside of _send or make it explicit in the documentation that the _send method must be overridden to support async.

I tend to agree that we shouldn't be defining re-try paradigms in the sdk (#62 (comment)); especially if you are hitting api-request limits than probably blocking with sleep isn't what you want anyways.

As for patching _send I think you may have to do that anyways so that you can use a e.g. aiohttp or another library which provides http methods that you can yield_from.