This is very clean. I am thinking that maybe we want to make a class that lives under ble, like ble.Bluetooth, ble.Device, or ble.BLE. Better suggestions welcomed. Then we have a singleton instance that is the device. We can then use properties, which we can't do with a regular module. So

if ble.bluetooth.enabled:
    ...
ble.bluetooth.enabled = False
print(ble.bluetooth.address)

etc.

Later there could be other things that live under ble, maybe message classes?? I don't know enough now to make good suggestions. Maybe ble should be bleio??

Some other examples of this kind of singleton class in CircuitPython are microcontroller.cpu (instance of microcontroller.Processor) and nvm.Bytearray.

Yes, I wanted to use a property for enabled and address but had two hesitations: 1. would need a class, 2. would break the current API.

Regarding having a class, I think best name would be Adapter, pretty common terminology in the BT world. We could keep all other classes like Central, Peripheral, Service, Characteristic inside a bleio module as well, but that would break compatibility with bluepy.

Let me know if you want me to move the functions to a Adapter singleton.

I vote to use a singleton.

We'll break compatibility with upstream due to our use of properties anyway. We'll break with bluepy because we need more APIs and their methods are non-standard camel case.

So, lets do what we think is best. Thanks!

Woo, let the Bluetooth overhaul begin! Expect many PRs soon :D

So we agree on bleio?

Ya, bleio works for me. *io is kinda lame but its consistent with our previous stuff and helps make it a unique name.

bleio is better than bleah :)

bleep? ;)

@tannewt @dhalbert Updated :)

@dhalbert Fixed!