This PR modifies the dispatch-py internals to build on the asyncio package in order to better integrate with frameworks like FastAPI, httpx, etc... and any other Python code that uses async/await constructs for I/O operations.
A couple of notable changes:
The signature of primitive functions is changed to always be async, this is the only breaking change
Due to interacting with the asyncio event loop, there are changes to the order of some operations. Notably, the depth-first traversal does not follow the same order anymore; this shouldn't have any impact on production applications since they wouldn't (shouldn't) rely on the order of async operations
In a few places, we are constructing temporary event loops (using a class similar to asyncio.Runner) to convert from blocking to asyncio code, for example in the http server we use in dispatch.run(). This a bit hacky and probably not optimal, we could do better by taking a dependency on aiohttp, I'll look into it in a follow up PR where I also want to investigate how we could integration the .dispatch() method with asyncio.
This PR modifies the dispatch-py internals to build on the
asynciopackage in order to better integrate with frameworks like FastAPI, httpx, etc... and any other Python code that uses async/await constructs for I/O operations.A couple of notable changes:
async, this is the only breaking changeIn a few places, we are constructing temporary event loops (using a class similar to
asyncio.Runner) to convert from blocking to asyncio code, for example in the http server we use indispatch.run(). This a bit hacky and probably not optimal, we could do better by taking a dependency onaiohttp, I'll look into it in a follow up PR where I also want to investigate how we could integration the.dispatch()method with asyncio.Fixes #122