You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The python code has been integrated in our project and can be modified and extended (a possible asyncio integration is possible) but we would prefer not to modify the C layers underneath (both api and implementation).
A separate set of classes is perfectly acceptable.
The C layer does not have to change, Python has enough tools to wrap callback based APIs into async/await APIs. (asyncio.get_running_loop().create_future() is one such tool.)
Consumer.run() is an example of a poblematic function since it blocks the thread, and therefor the ascynio event loop. Calling it via asyncio.to_thread() might be enough. It is way to soon for me to say with any confidence, however.
I saw your branch test_asyncio, I recommend adding the following to pyproject.toml and updating to the latest pytest-asyncio:
[tool.pytest.ini_options]
asyncio_mode = "auto"
I personally like that better than pytestmark = pytest.mark.asyncio.
PS. why is python-qpid-proton vendored? I am not against it, but I am curious.
Hi @Darsstar yes please don't take in consideration my branch (it was just to do a few tests with asyncio on this specific project). If you would like to contribute on this task and @Gsantomaggio agrees please assign it to you (so that everyone know if are working on it) and go ahead from scratch
Is your feature request related to a problem? Please describe.
At the moment our client is using as wrapper the the qpid-proton client for python: https://github.com/apache/qpid-proton/tree/main/python
which is not supporting asynchronous APIs
The python code has been integrated in our project and can be modified and extended (a possible asyncio integration is possible) but we would prefer not to modify the C layers underneath (both api and implementation).
We can think on a possible python asyncio integration, maybe creating separate class for this like uamqp si currently doing: https://github.com/Azure/azure-sdk-for-python/blob/main/sdk/servicebus/azure-servicebus/azure/servicebus/_pyamqp/aio/_sender_async.py
Describe the solution you'd like
Explore possible solutions
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: