Asynchronous changes?
Closed this issue · 3 comments
Hi. What do you think about adding asynchronous changes? The hue bulbs takes some time before the connection is closed (about one or two second), so if I try to control multiple bulbs at once, they change slowly one by one.
An asynchronous/fire&forget approach to making changes would be really useful here. I wrapped your library with threading in my hue-tradfri bridge and it is just a few lines of code. But I don't know if it fits your idea of what this library should do.
Hi Jan -
Ah, that's an interesting idea. I haven't done anything time-critical yet, so haven't hit this problem. I wonder how many simultaneous requests the bridge could cope with...
I think my instinct is to keep things simple at present, and let people wrap the library, as you've done.
If I did make an async version, I might use Python 3's async stuff rather than threads, but that would need to wait until it was a bit more widely distributed. A lot of it could be done by subclassing the Resource object, and overriding the call() method with one that used, say, aiohttp instead of the requests module...
Mmm...
I tried to use the asyncio library, but I couldn't get it working as I needed. While it was asynchronous, it was still running in a single thread so the delay was there, just in another part of the code. But maybe I just used it a wrong way... You may have a better luck with that.
Anyway, I don't think there ever will be a point when python2 can be generally pronounced obsolete. If it didn't happen by now, it won't happen as long as python is widely used. :-)
No, I agree - most of my work is still in Python 2.
But most of my new projects are in Python 3, and think we've reached the point where that will soon be the norm. Since Qhue is a fairly new module, it may not be used too much in legacy code, so perhaps the majority of Qhue-based projects will be in Python 3.
For now, though, your approach looks like a good one!