-
Notifications
You must be signed in to change notification settings - Fork 3
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
Enable reporting unknown types #333
base: strict-basedpyright
Are you sure you want to change the base?
Conversation
6cbd87e
to
e434651
Compare
Since we have the reportUnknownParameterType for basedpyright enabled, we can't leave `*args` or `**kwargs` unannotated anyways, so we might as well enforce it properly.
@@ -110,7 +110,7 @@ | |||
autodoc_member_order = "bysource" | |||
|
|||
# Default options for all autodoc directives | |||
autodoc_default_options = { | |||
autodoc_default_options: dict[str, Any] = { |
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 don't see how these kind of type annotations are better
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.
Yeah, the thing is, pyright would otherwise mark this as dict[str, Unknown]
and with Unknown
being banned, if a wildcard type is indeed what we want, it must be declared explicitly like this. That's also one of the reasons why these rules might be a bit too strict.
@@ -153,7 +153,7 @@ def run(self) -> list[AttributeTablePlaceholder]: | |||
def build_lookup_table(env: BuildEnvironment) -> dict[str, list[str]]: | |||
# Given an environment, load up a lookup table of | |||
# full-class-name: objects | |||
result = {} | |||
result: dict[str, list[str]] = {} |
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.
But for these ones it's interesting to have type checking
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 agree, in some cases, being forced to explicitly declare the annotations can be very helpful to the type checker, it is nice that this would now be a requirement, where types can't be easily inferred.
@@ -66,7 +66,7 @@ def __init__(self, exc: httpx.HTTPStatusError): | |||
@property | |||
def msg(self) -> str: | |||
"""Produce a message for this error.""" | |||
msg_parts = [] | |||
msg_parts: list[str] = [] |
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 already have things like that all over the place in more-packets
@@ -477,7 +479,7 @@ def test_nbt_bigfile(): | |||
data = bytes.fromhex(data) | |||
buffer = Buffer(data) | |||
|
|||
expected_object = { # Name ! Level | |||
expected_object: FromObjectType = { # Name ! Level |
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 I find useful
I'm not against these new rules as I feel they are not the most annoying of the bunch, but I don't really know if the extra effort is worth the while. |
The worst / most annoying stuff are recursive types, like those in |
Type checking is useful when it uses the computer's power to mitigate our forgetfulness, but when it's going the opposite way I find it annoying 😆 . |
This PR is an experiment, just to see how the code-base would look like if we enabled reporting unknown types for basedpyright.
It's more of a prompt for discussion on whether or not this is worth it, I do not intend to merge this, at least not before this discussion takes place.
The issue with these rules is that they can sometimes be incredibly annoying to satisfy, it often means having to use a bunch of type-casts or just ignoring them. However, in many cases, they can also be incredibly useful, as it's good to know when basedpyright can't recognize some type and needs some help in understanding it. Overall, it would definitely improve the type safety, but the question is whether it's even worth it.