Add missing ETH_P_ALL
identifier to socket
#11876
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It seems #10247/#11219 missed a couple identifiers in the
socket
stub (the_socket
stub seems good, though). This PR addssocket.ETH_P_ALL
(https://docs.python.org/3/library/socket.html#socket.ETH_P_ALL).There's also
AF_DIVERT
andPF_DIVERT
missing from thesocket
stub, as well, but I've omitted those from this PR for a couple reasons. These are only available on FreeBSD systems, which was correctly noted in the comment above their type annotations in_socket
, but the condition to check for this availability is (or at least seems to be) logically incorrect:The
sys.platform
documentation shows the correct (or at least a more correct) conditional statement:And similarly for the
socket
stub:All this essentially to ask if the current check (
sys.platform != "linux" and sys.platform != "win32" and sys.platform != "darwin"
) is just how typeshed has decided to check for FreeBSD systems, or if it would be preferable to use thesys.platform.startswith('freebsd')
check. And, if this would be preferred, should parsing and checking the version be included, as well?I also don't have a FreeBSD system to personally test with, so wasn't sure if I should let someone on an actual FreeBSD 14 system handle this (although, I suppose it wouldn't be too much trouble to spin up a FreeBSD VM if necessary).