proposed breaking change: change handle argument type in notification callbacks

[dlech]

This is a commonly reported problem: #724, #467 (it feels like it has come up more than this, but that is all I could find).

The solutions is to use functools.partial to wrap the callback function to include the required extra info.

But I'm wondering if it is worth making a breaking change to make it easier and more obvious. For example, we could replace the handle argument in the callback function with the BleakClient object itself. This would only break programs that are actually using the handle argument. I suspect that is not many because unless you are attaching the same callback to multiple characteristics, this information is not needed.

Originally posted by @dlech in #754 (comment)

[dlech]

Having thought about this a bit more, instead of replacing the handle argument with the BleakClient object, it would make more sense to replace it with a BleakGATTCharacteristic object. Then anyone using the handle argument would only have to make a small change (basically replace handle with char in the declaration and char.handle where it is read). Then we could add "parent" properties to be able to get the parent service of the characteristic and the parent BleakClient of the service.

[koenvervloesem]

I like your second suggestion, passing the characteristic instead of the handle to the callback function. This also feels more natural from a general point of view, as notifications are about the characteristic anyway.

[cooperlees]

+1 on the second option. Would be great to automatically get the Client + Characteristic in a callback by default. At the moment my code has it's own class to do this, but am happy for the breaking change and small refactor.

[chill-git]

Why not let the user provide an arbitrary reference?
When they install the callback, they can specify what it is they want to get back.