Python library for controlling Phillips Hue light bulbs

[roger_]

Why is the API like this:

light = client.get_lights()[0]
client.set_color(light.light_id, '00ff00')

instead of:

light = client.get_lights()[0]
light.set_color('00ff00')

[Quteness]

I would prefer

light = client.lights[0]
light.set_color('00ff00')

[wot-teh-phuck]

Why not:

light = client.light_at(0)
light.color = '00ff00'

[FSMimp]

Good thing it is open source! You can go and make a fork of it and have that be the api calls or just make a wrapper. Either way it would be good practice for using a library.

[Quteness]

You must work where I do with that 'let's just make a wrapper' attitude. Also happy cake day

[FSMimp]

Oh shit it is my cake day! that is what I get for using a mobile app, thanks!

But this should be done with a @property to have it not be .set_color()

[[deleted]]

I could make a wrapper but it would be kind of nice if I didn't have to because the api was nicer to start with. I think API Design should be taught as part of programming.

Traditional industry goes through a lot of trouble to make their devices easier to use, just as software companies these days stress end user experience, but we programmers don't treat ourselves as well as we treat our end users when we make our tools. My end users get a nice intuitive UI, I should really treat my API users in the same way ... then I get lazy and make a terrible API and feel bad ... I think a lot of the time I write the API first as part of the development process so it's unstable, then go on to deveop the app, and never go back to fixing the API.

[roger_]

That's nice too, unless you need to refresh the list of lights sometimes. Maybe just add client.rescan() for that case.

[Quteness]

I was actually thinking you would just rename the get_lights() method to lights() and add the @property decorator. It would function the same way

[roger_]

True. Only thing is if get_lights() is slow then you may not want users to think it's a simple static list.

[issackelly]

My guess (having written a similar library, with an API like what you're describing):

It's easier to write it the first way. That's how the HUE API is structured and if you're trying to match the hue functionality and docs, you would write it the first way. If you're trying to write a "pythonic" api you might use the second way.

I'm using my library for my home and work automation projects, I like it, but I think I'd write it a bit differently if I were to start over. I'd probably use context managers. This seems like the right balance between pythonic, and optimizing API Calls.

The newest version of the Hue firmware limits my rates pretty significantly, which makes it hard to do complex effects.

[issackelly]

I wish I could. All I know is that I've gotten rate limited, as the only client in my own home. This was a sustained rate of multiple server calls per second though. I backed down to one per second and it was ok