Skip to content

Conversation

@Divyanshudevtalla
Copy link

Added new Bluetooth constants for Python 3.14 as requested by @dlech.

Updated _Address type alias.

Added Linux and Windows constants.

Followed the ordering from PR #15209 as suggested.

@github-actions

This comment has been minimized.

@dlech
Copy link

dlech commented Jan 27, 2026

This is missing changes similar to:

# Bluetooth constants which aren't on the GitHub Actions runners, see #15207
(_?socket\.AF_BLUETOOTH)?
(_?socket\.BDADDR_ANY)?
(_?socket\.BDADDR_LOCAL)?
(_?socket\.BTPROTO_HCI)?
(_?socket\.BTPROTO_L2CAP)?
(_?socket\.BTPROTO_RFCOMM)?
(_?socket\.BTPROTO_SCO)?

@dlech
Copy link

dlech commented Jan 27, 2026

This is also missing modifications to stdlib/socket.pyi.

@dlech
Copy link

dlech commented Jan 27, 2026

It would also be helpful if you could try running a BSD in a virtual machine and check out the constants added there.

# AF_NETLINK, AF_TIPC) or strings/buffers (AF_UNIX).
# See getsockaddrarg() in socketmodule.c.
_Address: TypeAlias = tuple[Any, ...] | str | ReadableBuffer
_Address: TypeAlias = tuple[Any, ...] | str | ReadableBuffer | int
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment above should be modified to explain why int is included.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing this out! I’ll update the comment to explain why int is included.

Comment on lines 38 to 39
SOCK_CLOEXEC: Final[int]
SOCK_NONBLOCK: Final[int]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two should not be changed to have a condition on the Python version.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for correction! I`ve updated the change so these are not conditional on the python version

if sys.version_info >= (3, 14):
SOCK_CLOEXEC: Final[int]
SOCK_NONBLOCK: Final[int]
BDADDR_BREDR: Final[int]
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect all of the Bluetooth stuff to be grouped together with the existing "semi-documented constants" below line 635.

# Semi-documented constants

Same comment applies to the Windows-only constants.

@Divyanshudevtalla
Copy link
Author

"Hi @dlech, thank you for the feedback! I have updated the PR as requested:

Moved all Bluetooth constants to the 'Semi-documented constants' section (Line 640+) in _socket.pyi.

Removed the incorrect version guards from SOCK_CLOEXEC and SOCK_NONBLOCK.

Added the necessary documentation comment to the _Address type alias on Line 14.

Added all new constants to tests/stubtest_allowlists/linux.txt to fix the CI failures.

The tests should turn green shortly. Please let me know if there is anything else I should adjust!

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@Divyanshudevtalla
Copy link
Author

Hi @dlech, I have been working on resolving the CI failures and have managed to clear about 44 of them. I've added the Bluetooth constants to socket.pyi and _socket.pyi under the (3, 14) guard and updated the stubtest allowlist.

However, I'm currently stuck with 19 remaining failures related to redefinition errors. Even though I've removed the duplicate blocks I found, the logs still show conflicts between the new definitions (Line 586) and existing ones (Line 677).

Since I'm a student contributor, could you please guide me on whether I should be moving the existing constants into the new version-guarded block, or if there's a specific organization for these Bluetooth stubs that I'm missing? Thank you for your patience!

# These would ideally be special-cased by type checkers; see https://github.com/python/mypy/issues/2220
xml.etree.ElementTree.Element.__iter__
xml.etree.cElementTree.Element.__iter__
_socket.BDADDR_BREDR
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see anything existing in this file for _socket.*, so I don't think we should be adding anything here.

(_?socket\.BTPROTO_RFCOMM)?
(_?socket\.BTPROTO_SCO)?

_socket.BDADDR_BREDR
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
_socket.BDADDR_BREDR
(_?socket.BDADDR_BREDR)?

This and all the others being added need to follow the existing pattern.

Comment on lines 102 to 103
_socket.SOL_L2CAP
_socket.SOL_SCO
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
_socket.SOL_L2CAP
_socket.SOL_SCO

These are duplicate. Please check the list for other duplicates. Sorting the list in alphabetical order should make it easy to catch these.

_Address: TypeAlias = tuple[Any, ...] | str | ReadableBuffer
_Address: TypeAlias = (
tuple[Any, ...] | str | ReadableBuffer | int
) # int is included because of device_id not packed in a tuple is now accepted for BTPROTO_HCI
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment should be part of the existing comment above, not a new comment.

SOL_SCO: Final[int]

# --------------------
# Semi-documented constants
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't move this comment. Instead the new Bluetooth constants should be added somewhere below here.

@github-actions

This comment has been minimized.

@Divyanshudevtalla
Copy link
Author

Hi @dlech, thank you for the guidance! I've addressed all the feedback:

Fixed Allowlist Patterns: Removed _socket from common.txt and moved it to linux.txt using the individual regex format.

Deleted the (_?socket.)? wildcard from the allowlist to ensure specific testing.

Cleaned Duplicates: Consolidated all constants into the 3.14 version check block and removed the redundant definitions.

Alphabetical Order: Sorted all newly added constants from A to Z as requested.

I’ve also resolved the merge conflicts with the main branch. Please let me know if everything looks correct now!

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions
Copy link
Contributor

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉

@Divyanshudevtalla
Copy link
Author

Hi @dlech , I’ve been working on resolving the stubtest failures for the Python 3.14 build. I managed to solve most of them, but I’m down to the final 11 failures related to _socket constants
​I’ve tried matching the regex patterns to the error logs, but they are still showing as 'unused' or failing. Since these involve the new Python 3.14.2 update, I wanted to ask if there’s a specific formatting trick for these Bluetooth constants or if they should be moved to a different allowlist.
​Would you mind taking a quick look at my latest push?

@dlech
Copy link

dlech commented Jan 29, 2026

To be honest, this is not going well. The latest changes are not an improvement. And there are many previous comments that have not been addressed yet.

Instead of focusing on getting the CI to pass, I suggest to really study the code and look for the patterns and logic in it.

For example, we can see that "darwin" does not support Bluetooth sockets at all. So logically, we should conclude that no Bluetooth constants should be added to the allow lists for darwin. Similarly, logically, we should not be including constants that were introduced in Python 3.14 in a file named linux-py312.txt, they are different Python versions.

There are still lots of things missing and things in the wrong place. By looking at the existing patterns in the code and in #15209, one should be able to find all of the places were we should be adding the new constants. If you are not able to see these patterns and extrapolate from them, then you might not be ready to take on this task yet.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants