Skip to content
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

Open
wants to merge 3 commits into
base: strict-basedpyright
Choose a base branch
from

Conversation

ItsDrike
Copy link
Member

@ItsDrike ItsDrike commented Jul 13, 2024

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.

@ItsDrike ItsDrike added t: enhancement Improvement to an existing feature p: 3 - low This can wait do-not-merge This PR can be reviewed, but cannot be merged now a: internal Related to internal API of the project labels Jul 13, 2024
@ItsDrike ItsDrike marked this pull request as ready for review July 13, 2024 10:32
@ItsDrike ItsDrike force-pushed the enable-unknown-type-reporting branch from 6cbd87e to e434651 Compare July 13, 2024 10:34
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] = {
Copy link
Contributor

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

Copy link
Member Author

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]] = {}
Copy link
Contributor

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

Copy link
Member Author

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] = []
Copy link
Contributor

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
Copy link
Contributor

Choose a reason for hiding this comment

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

This I find useful

@LiteApplication
Copy link
Contributor

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.

@ItsDrike
Copy link
Member Author

The worst / most annoying stuff are recursive types, like those in nbt.py, since pyright can only understand them up to 1 level deep. After that, they become Unknown and casts are necessary. That was definitely the most annoying part of this.

@LiteApplication
Copy link
Contributor

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 😆 .

@py-mine-ci-bot py-mine-ci-bot bot added the s: stale Has had no activity for a while (will be closed for inactivity/marked up for grabs soon) label Oct 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a: internal Related to internal API of the project do-not-merge This PR can be reviewed, but cannot be merged now p: 3 - low This can wait s: stale Has had no activity for a while (will be closed for inactivity/marked up for grabs soon) t: enhancement Improvement to an existing feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants