Typing almost non-existent

[brianreinhold]

Is there a place to open up a discussion versus an issue?

For someone using this library for the first time it makes it extremely difficult when a vast majority of variables are typed as Incomplete or None. I have to admit that I dislike dynamic typing as it is hard to follow someone else's code when nothing is typed. The same goes for the examples.

I am trying to make a decision as whether to use the low-level bluetooth or this package on the PICO-W. I get the impression that the low-level library is better typed and it follows the Bluetooth spec more closely. Since I understand the latter quite well and have done a lot of work in C and Java in BTLE in various platforms the low-level option may be a better approach and easier to follow. But it comes with a warning that it is subject to change, so I am not really sure where to go.

is there any active discussion forum for this library and documentation that describes the API and variables (besides going to the source code)? The ReadMe leaves out a lot of necessary details. I will need to write a central/client for new BTLE profiles (GHS in particular) and a host of proprietary devices. Are there things that one cannot do at this level that one can do using the low-level?

Thanks

[mattytrentini]

There is a discussion board on the main micropython repository. I can't convert this directly into a discussion post but I could transfer it to a micropython issue (different repo) and then to a discussion. Let me know if you'd prefer that!

You should also be aware of the aioble library if you're not already - it's a much more productive way to build BLE clients.

As for typing, it wouldn't hurt to add typing information to the low level BLE library but that may be best done with stubs. I don't think it's possible to add typing information to MicroPython features implemented solely in C. Perhaps micropython-stubber can help?

[brianreinhold]

@mattytrentini thanks for your reply. I will check out these boards. I should point out that I need to build a generic health device client which supports not only BT SIG health device standards including the new GHS but proprietary devices that can behave in a who-knows-what way. Its the latter that poses the big challenge! If the high level API allows me to do anything I could do in the low level API then it probably makes more sense to use the high level API even though I can see the correspondence between the low-level API and BTLE GAP/GATT functionality much more clearly. I have done a lot of work on the Nordic and Renesas platforms (C) and Android (Java) and these APIs look quite similar to the low-level API with its basic callback structure so that familiarity biases me toward the low-level choice.