Use AnyIO instead of AsyncIO

[thedrow]

Is your feature request related to a problem? Please describe.
I'd like to use uamqp with trio. trio is another event loop implementation for Python which uses structured concurrency concepts.

Describe the solution you'd like
Instead of implementing asynchronous operations using asyncio the async_ops module should instead be implemented with AnyIO.
AnyIO abstracts the underlying event loop and allows you to choose which one you want to use.

Furthermore, it will save you from maintaining the asyncio implementation itself.
For example, currently the implementation uses the keyword argument loop when calling asyncio.shield. This will be deprecated in Python 3.10.

By using AnyIO, you will offload this maintenance burden.

Describe alternatives you've considered
I can already use this library with trio-asyncio but native support would be nicer.

Additional context
None.

[thedrow]

I'm not going to work on this until we have a consensus on what needs to be done.
Please address this issue as quickly as possible. Thanks :).

[annatisch]

Thanks @thedrow!
We wanted to make these changes about a year ago, but at the time it wasn't easy because we were using some very asyncio-specific features like run_in_executor for which we needed to pass through the event loop.
However I think our dependency on the asyncio loop has now been refactored out, in which case it would be awesome to make this change as you've proposed.

Though I know we're using asyncio.sleep - is trio compatible with that?

[thedrow]

Of course it does. Trio also supports running tasks in threads.
AnyIO abstracts sleep as well as most other mechanisms.

Is there any chance you'll refactor this on your own?
If not, where are the tests for the asynchronous code?

[annatisch]

Thanks @thedrow - yes it is likely we will refactor this imminently.
We're already seeing warnings about the passing around of loop, so I would like to get that cleaned up - although we may not get to it within a given timeframe.

I will do my best to scope out the needed work within the next few days.

[thedrow]

@annatisch Any updates?

[annatisch]

Hi @thedrow - I've taken a look and I don't think there's too much work involved.
However we're are currently discussing internally whether we want to invest further in the C-binding-based project, or whether we want to remove the C layer and replace with a pure-python based implementation (prototype currently ongoing in the pyproto branch).
If we opt for the latter - we could build in AnyIO support from the ground-up.

We are also cautious about taking a direct dependency on the lib - so we we're working through what the implementation look like if it were both fully-compatible with AnyIO as well as standalone.

Will keep this thread updated :)

[thedrow]

@annatisch Pinging you once more, with feeling ;)

[JonasKs]

Hi @annatisch, did you land on anything? 😊

[annatisch]

Hi @JonasKs!
We are currently rewriting this library in pure Python, with the first preview targeted for early 2022.
Development is progressing in this branch: https://github.com/Azure/azure-uamqp-python/tree/pyproto

Given that we are currently rebuilding from scratch - we will not be making these changes to the C-based implementation of uamqp.
So then the question becomes, will the pure Python version of the library use AnyIO. The first preview will not unfortunately - we wanted to focus our efforts on correct end-to-end implementation of the protocol. In subsequent releases we plan to drop the hard dependency on AsyncIO to allow more flexibility here.
My earlier tests with AnyIO (albeit 2 years ago now) introduced a significant perf regression that prevented us from quickly making the shift earlier and needed deeper investigation.

[JonasKs]

Awesome! Thanks for the quick reply. Good luck with the release 🚀