Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separating OS specific keyword arguments #623

Closed
hbldh opened this issue Aug 12, 2021 · 2 comments
Closed

Separating OS specific keyword arguments #623

hbldh opened this issue Aug 12, 2021 · 2 comments
Assignees
Labels
Backend: BlueZ Issues and PRs relating to the BlueZ backend Backend: Core Bluetooth Issues and PRs relating to the Core Bluetooth backend Backend: WinRT Issues or PRs relating to the WinRT backend enhancement New feature or request Opinions Appreciated Please add an opinion on your desired resolution on this issue!

Comments

@hbldh
Copy link
Owner

hbldh commented Aug 12, 2021

  • bleak version: 0.12.0
  • Python version: All
  • Operating System: All

Bleak has several OS specific keyword, all of which are integrated into the regular **kwargs input to methods. The primary means of making users aware of what they can do to affect their current environment is through documentation. The documentation does provide this, but it is evidently not enough, given the amount of issues that e.g. asks why device="hci1 does not work in Windows to select another Adapter.

@dlech proposed two different ways of improving Bleak in this regards:

  1. Using a win_, macos_, and linux_ prefix to keyword arguments that are os specific.
  2. Using a win={"x"=1. "y"=2, ...} style of OS specific grouping of parameters.

Both will render nicely with black and both relays the desired effect in my mind. @hbldh prefers the second way, but given that Bleak currently has few OS specific parameters it will be almost equal. Given that I, creator of Bleak, has much less use of it that most everyone else that will read this will have, I am more that ready to yield to public demand.

I vote 2, and everyone else that votes will have his or her's vote counted equally. At the first of September, I will start to implement the winning choice. IF someone beats me to the implementation of one of the choices, I will take that one.

@hbldh hbldh added enhancement New feature or request Backend: BlueZ Issues and PRs relating to the BlueZ backend Opinions Appreciated Please add an opinion on your desired resolution on this issue! Backend: Core Bluetooth Issues and PRs relating to the Core Bluetooth backend Backend: WinRT Issues or PRs relating to the WinRT backend labels Aug 12, 2021
@hbldh hbldh self-assigned this Aug 12, 2021
@dlech
Copy link
Collaborator

dlech commented Aug 20, 2021

Option 2 seems like it could be adapted to use typing.TypedDict in the future (requires Python 3.8) as well for better type hints.

dlech added a commit that referenced this issue Jul 13, 2022
This adds a new bluez kwarg for backend-specific args and deprecates
the existing filters arg as per #623.
dlech added a commit that referenced this issue Jul 13, 2022
This adds a new bluez kwarg for backend-specific args and deprecates
the existing filters arg as per #623.
dlech added a commit that referenced this issue Jul 13, 2022
This adds a new bluez kwarg for backend-specific args and deprecates
the existing filters arg as per #623.
dlech added a commit that referenced this issue Jul 13, 2022
This adds a new bluez kwarg for backend-specific args and deprecates
the existing filters arg as per #623.
dlech added a commit that referenced this issue Jul 13, 2022
This adds a new bluez kwarg for backend-specific args and deprecates
the existing filters arg as per #623.
dlech added a commit that referenced this issue Jul 29, 2022
Added
-----

* Added new ``assigned_numbers`` module and ``AdvertisementDataType`` enum.
* Added new ``bluez`` kwarg to ``BleakScanner`` in BlueZ backend.
* Added support for passive scanning in the BlueZ backend. Fixes #606.
* Added option to use cached services, characteristics and descriptors in WinRT backend. Fixes #686.
* Added ``PendingDeprecationWarning`` to use of ``address_type`` as keyword argument. It will be moved into the
  ``winrt`` keyword instead according to #623.
* Added better error message when adapter is not present in BlueZ backend. Fixes #889.

Changed
-------

* Add ``py.typed`` file so mypy discovers Bleak's type annotations.
* UUID descriptions updated to 2022-03-16 assigned numbers document.
* Replace use of deprecated ``asyncio.get_event_loop()`` in Android backend.
* Adjust default timeout for ``read_gatt_char()`` with CoreBluetooth to 10s. Merged #891.
* ``BleakScanner()`` args ``detection_callback`` and ``service_uuids`` are no longer keyword-only.
* ``BleakScanner()`` arg ``scanning_mode`` is no longer Windows-only and is no longer keyword-only.
* All ``BleakScanner()`` instances in BlueZ backend now use common D-Bus object manager.
* Deprecated ``filters`` kwarg in ``BleakScanner`` in BlueZ backend.
* BlueZ version is now checked on first connection instead of import to avoid import side effects. Merged #907.

Fixed
-----

* Documentation fixes.
* On empty characteristic description from WinRT, use the lookup table instead of returning empty string.
* Fixed detection of first advertisement in BlueZ backend. Merged #903.
* Fixed performance issues in BlueZ backend caused by calling "GetManagedObjects" each time a
  ``BleakScanner`` scans or ``BleakClient`` is connected. Fixes #500.
* Fixed not handling "InterfacesRemoved" in ``BleakClient`` in BlueZ backend. Fixes #882.
* Fixed leaking D-Bus socket file descriptors in BlueZ backend. Fixes #805.
@dlech dlech mentioned this issue Jul 29, 2022
dlech added a commit that referenced this issue Jul 29, 2022
Added
-----

* Added new ``assigned_numbers`` module and ``AdvertisementDataType`` enum.
* Added new ``bluez`` kwarg to ``BleakScanner`` in BlueZ backend.
* Added support for passive scanning in the BlueZ backend. Fixes #606.
* Added option to use cached services, characteristics and descriptors in WinRT backend. Fixes #686.
* Added ``PendingDeprecationWarning`` to use of ``address_type`` as keyword argument. It will be moved into the
  ``winrt`` keyword instead according to #623.
* Added better error message when adapter is not present in BlueZ backend. Fixes #889.

Changed
-------

* Add ``py.typed`` file so mypy discovers Bleak's type annotations.
* UUID descriptions updated to 2022-03-16 assigned numbers document.
* Replace use of deprecated ``asyncio.get_event_loop()`` in Android backend.
* Adjust default timeout for ``read_gatt_char()`` with CoreBluetooth to 10s. Merged #891.
* ``BleakScanner()`` args ``detection_callback`` and ``service_uuids`` are no longer keyword-only.
* ``BleakScanner()`` arg ``scanning_mode`` is no longer Windows-only and is no longer keyword-only.
* All ``BleakScanner()`` instances in BlueZ backend now use common D-Bus object manager.
* Deprecated ``filters`` kwarg in ``BleakScanner`` in BlueZ backend.
* BlueZ version is now checked on first connection instead of import to avoid import side effects. Merged #907.

Fixed
-----

* Documentation fixes.
* On empty characteristic description from WinRT, use the lookup table instead of returning empty string.
* Fixed detection of first advertisement in BlueZ backend. Merged #903.
* Fixed performance issues in BlueZ backend caused by calling "GetManagedObjects" each time a
  ``BleakScanner`` scans or ``BleakClient`` is connected. Fixes #500.
* Fixed not handling "InterfacesRemoved" in ``BleakClient`` in BlueZ backend. Fixes #882.
* Fixed leaking D-Bus socket file descriptors in BlueZ backend. Fixes #805.
@dlech
Copy link
Collaborator

dlech commented Oct 3, 2022

This has been implemented.

@dlech dlech closed this as completed Oct 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backend: BlueZ Issues and PRs relating to the BlueZ backend Backend: Core Bluetooth Issues and PRs relating to the Core Bluetooth backend Backend: WinRT Issues or PRs relating to the WinRT backend enhancement New feature or request Opinions Appreciated Please add an opinion on your desired resolution on this issue!
Projects
None yet
Development

No branches or pull requests

2 participants