René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Inconsistency in handling Bluetooth addresses","articleBody":"# Bug report\n\n1. The format accepted by BTPROTO_HCI protocol is incorrectly documented.\n   * it accepts a bytes object `bdaddr`, not a tuple.\n   * `bdaddr` is a bytes object, not a string.\n2. Some protocols accept `bdaddr` as a string, others accept it as a bytes object. `getsockname()` returns it as a string or a bytes object, and this is not always consistent with the accepted type.\n3. `getsockname()` not always return an address in the acceptable format. It returns `device_id` when the acceptable format is a tuple `(device_id,)`, can return a string when the acceptable format is a bytes object.\n\nFirst problem should be solved by updating the documentation.\n\nFor second problem, I propose to make both string and bytes be accepted as a Bluetooth address. Also, if a 1-tuple is accepted, then its element should be accepted, and if `bdaddr` is accepted, then a 1-tuple `(bdaddr,)` should be accepted.\n\nThe third problem cannot be resolved in backward compatible way. The solution for the second problem formally fixes incompatibility between input and output formats, but formats are still inconsistent between protocols. And after adding support for `hci_channel` (see #70145), the type of the `getsockname()` result  will depend on the `hci_channel` value.\n\n\u003c!-- gh-linked-prs --\u003e\n### Linked PRs\n* gh-132118\n* gh-132482\n* gh-132486\n* gh-132497\n* gh-132525\n\u003c!-- /gh-linked-prs --\u003e\n","author":{"url":"https://github.com/serhiy-storchaka","@type":"Person","name":"serhiy-storchaka"},"datePublished":"2025-04-04T18:54:38.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/132099/cpython/issues/132099"}