For cases where we know what the ID represents, something like "zone_id" or "device_id" would be more appropriate.

In the case of the base ID of any generic item in the client, "item_id" doesn't provide any more information than "id". Simply prefixing it with an underscore would avoid the collision. So, "_id".

However, in almost all cases the existence of Python's id() is irrelevant. When testing the identity of two objects, you'd hope to have a handle on each - not their memory addresses, which id() represents.

The fact that:

id(obj_a) == id(obj_b)

is identical to the far more Pythonic:

obj_a is obj_b

means I won't be heartbroken about this collision.

I was going to address the above concerns in a revision of this pull request -- what changed in the manual merge?

Ah, no worries there. Need to push out a release ASAP for someone. @sudorandom removed __format_filter_dict() in b1c09f9 which caused a conflict. The manual merge only dealt with the conflict so we could tag a release.

None of the mentioned concerns have been addressed. Rebase from master and those can be addressed for v2.2.0

Ahh, gotcha. Just curious. I'll rebase and prepare some more stuff when I get back in tomorrow.

Regarding the questions around get_thing(thing_id) vs. get_thing(id) in this change, I noticed we were using just id in other places in the code, so tried to bring some consistency to it. I only picked the latter since the former's signature seemed redundant when I read it, given the context that each were in.

If everyone agrees they'd like to stick with the thing_id convention, I'll revert them in the another pull request shortly. Thoughts are welcome.

id is fine since the signatures are within a context.