-
Notifications
You must be signed in to change notification settings - Fork 62
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
Update next_event
annotation to reflect possible return types
#144
Conversation
The type of the return value is from if event not in [NEED_DATA, PAUSED]:
self._process_event(self.their_role, cast(Event, event)) which I presume mutates the event, but it does not return a value so the type is not narrowed. |
I don't like the idea of exposing |
Unfortunately not. Since those types are narrower than |
This change seems good, it's unfortunate we got some formatting changes from black. Could you separate the formatting changes and change to the types into two separate commits so I can rebase merge them? |
They are two separate commits already, here's a separate PR for the format changes #145 though. I can drop the format commit from this PR if you want to merge that one separately. Note this PR will still fail mypy without an additional cast or change to |
I've rebased onto |
Thanks, I'll merge this and #151 and consolidate if required. |
Hi! I'm updating httpcore's type annotations (encode/httpcore#526) to be compatible with the latest h11 version and encountering a difficulty with the type annotations on
next_event
. Since the return type includesSentinel
which is a private type in h11, the return type in httpcore cannot be defined correctly.To resolve this, the
Sentinel
type could be exposed publicly. However, arbitrary sentinels cannot be handled by downstream libraries. Instead, they should have a well defined set of sentinels that they know to handle.NEEDS_DATA
andPAUSED
are already publicly exposed and are the two sentinel types that can be returned byneeds_data
. Narrowing the type definition to these specific types will confer to consumers that they should handle these explicit sentinel types. If you add more sentinel types in the future, type checkers will warn users that they are not handling all of the possible return types for this function.There may be other
Sentinel
return type annotations that could/should be updated as well.