Asyncio interoperability is required for what I'm working on, so I've came up with a simple solution. There is no change to the already existing client or handlers. The asyncio client expands on the base threaded implementation. The completely separate implementation ensures no breaking changes.
Python version support
The installed library may work as before. Using the asyncio implementation is optional as it is a separate package, it will not be imported unless explicitly wanted. However the testing will require it to work making Python 2 not supported anymore. (I'd argue that is a good thing)
This PR will only work with python 3.7+ in its current state. I'd argue that's also acceptable, 3.6 is nearing its EOL. Though this could be changed to support 3.6 as well.
Further work
The KazooRetry implementation cannot be used with the new asyncio API. I'm on the fence about re-implementing it as using a general solution would likely be fine. If I used https://github.com/kaelzhang/python-aioretry for example, it would impose new dependencies though.
More tests would be nice definitely. However the wrapper API is so simple, that it may actually be unnecessary.
I'm going to use a build of this fork. Depending on my experiences I'll likely push updates here as necessary. However, I'm not sure if I'll have time to make this a complete PR with coverage and extended python version support.
Fixes (or attempts to fix) #185 and #499.
Asyncio interoperability is required for what I'm working on, so I've came up with a simple solution. There is no change to the already existing client or handlers. The asyncio client expands on the base threaded implementation. The completely separate implementation ensures no breaking changes.
Python version support
Further work
The KazooRetry implementation cannot be used with the new asyncio API. I'm on the fence about re-implementing it as using a general solution would likely be fine. If I used https://github.com/kaelzhang/python-aioretry for example, it would impose new dependencies though.
More tests would be nice definitely. However the wrapper API is so simple, that it may actually be unnecessary.
I'm going to use a build of this fork. Depending on my experiences I'll likely push updates here as necessary. However, I'm not sure if I'll have time to make this a complete PR with coverage and extended python version support.