-
-
Notifications
You must be signed in to change notification settings - Fork 352
typecheck trio/_abc.py #2703
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
typecheck trio/_abc.py #2703
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2703 +/- ##
=======================================
Coverage 98.88% 98.88%
=======================================
Files 113 113
Lines 16482 16483 +1
Branches 3000 3000
=======================================
+ Hits 16299 16300 +1
Misses 126 126
Partials 57 57
|
c79de19
to
b1bcb62
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, though I'm not very experienced with sockets so someone else might want to check that bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems good! Discussion about what to do with _SocketType
goes into #2705 so I think that's fine.
I'm also not too familiar with sockets so... not completely sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went ahead and checked against typeshed just to make sure the socket types are correct!
My only concern is related to going from =None
in the def socket(...)
classmethod. Why was it done this way to begin with @njsmith?
trio/_abc.py
Outdated
def socket(self, family=None, type=None, proto=None): | ||
def socket( | ||
self, | ||
family: socket.AddressFamily | int = socket.AF_INET, | ||
type: socket.SocketKind | int = socket.SOCK_STREAM, | ||
proto: int = 0, | ||
) -> _SocketType: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meh, I don't really feel comfortable changing away from the =None
without knowing why exactly they're here in the first place. Additonally, in typeshed this is how a similar function is defined:
if sys.platform == "win32":
def socketpair(family: int = ..., type: int = ..., proto: int = 0) -> tuple[socket, socket]: ...
else:
def socketpair(
family: int | AddressFamily | None = None, type: SocketType | int = ..., proto: int = 0
) -> tuple[socket, socket]: ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually figuring out the value of the defaults required a bit of digging, and it took me a bit to be certain enough that they were static and not dynamic or something, given that pretty much all default values in typeshed is = ...
. I wouldn't have set the default values to anything but ...
if not for typeright --verifytypes
complaining when default values aren't explicit.
Lines 270 to 289 in 315dbed
def socket( | |
family=_stdlib_socket.AF_INET, | |
type=_stdlib_socket.SOCK_STREAM, | |
proto=0, | |
fileno=None, | |
): | |
"""Create a new Trio socket, like :class:`socket.socket`. | |
This function's behavior can be customized using | |
:func:`set_custom_socket_factory`. | |
""" | |
if fileno is None: | |
sf = _socket_factory.get(None) | |
if sf is not None: | |
return sf.socket(family, type, proto) | |
else: | |
family, type, proto = _sniff_sockopts_for_fileno(family, type, proto, fileno) | |
stdlib_socket = _stdlib_socket.socket(family, type, proto, fileno) | |
return from_stdlib_socket(stdlib_socket) |
does have explicit logic for
None
though, so reverting the default value to None
seems eminently plausible.
Given that we're (to the extent possible) only changing typing, and not any behaviour, I don't think we need to be 100% certain that all the types are correct and I expect some incorrect signatures to slip through, and/or existing weird behavior that surfaces because of previously untyped code now being typechecked, that will require followup PRs/releases. |
The failing RTD build is due to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems good to me.
No description provided.