Repository navigation
bring BTPROTO_SCO inline with other Bluetooth protocols #69232
Description
| BPO | 25044 |
|---|---|
| Nosy | @vadmium |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2015-09-09.15:27:22.466>
labels = ['extension-modules', 'type-feature', '3.11']
title = 'bring BTPROTO_SCO inline with other Bluetooth protocols'
updated_at = <Date 2021-12-27.02:36:57.111>
user = 'https://bugs.python.org/TimTisdall'bugs.python.org fields:
activity = <Date 2021-12-27.02:36:57.111>
actor = 'ajaksu2'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2015-09-09.15:27:22.466>
creator = 'Tim.Tisdall'
dependencies = []
files = []
hgrepos = []
issue_num = 25044
keywords = []
message_count = 3.0
messages = ['250316', '250340', '250372']
nosy_count = 2.0
nosy_names = ['martin.panter', 'Tim.Tisdall']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue25044'
versions = ['Python 3.11']
Activity
TimTisdall commentedon Sep 9, 2015
All of the BTPROTO_ protocols accept tuples with Bluetooth addresses as regular strings. SCO accepts a byte-string which represents a Bluetooth address. The change was made at 23ab586c427a
With the current implementation we get this error:
This is because socket.BDADDR_ANY is a string while the bind() is expecting a binary string. So the workaround would be to call x.bind(socket.BDADDR_ANY.encode()) .
Is it acceptable to change it to accept a regular string to match the other address methods and constants? This would be essentially a breaking change, however on something that wasn't really documented prior to bpo-24984 .
I'll submit a patch when the repo is back up...
vadmium commentedon Sep 9, 2015
Perhaps making it accept both bytes and text strings is a sensible option. Similar to how AF_INET can bind to both "localhost" and b"localhost".
TimTisdall commentedon Sep 10, 2015
Yes, then any existing implementations will continue to work.
One sticky issue with all of this... there's no existing tests as per bpo-7687 .