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

no-any-explicit false positive with type parameter default Any #861

Open
jorenham opened this issue Jan 12, 2025 · 4 comments
Open

no-any-explicit false positive with type parameter default Any #861

jorenham opened this issue Jan 12, 2025 · 4 comments
Labels
bug Something isn't working topic-any upstream

Comments

@jorenham
Copy link
Collaborator

Describe the problem

There's no explicit Any here:

a = slice(None)
b: slice = a

But the following error is reported:

Explicit "Any" is not allowed (no-any-explicit) [Ln 2, Col 1]

I'm guessing this is because the type parameters of slice default to Any. But I don't see why such an implicit Any should be considered as explicit.

Gist to reproduce

a = slice(None)
b: slice = a

Severity

annoying but workaround is available

Your Environment

basedmypy 2.9.1 (compiled: yes)
Based on mypy 1.14.1

@jorenham jorenham added bug Something isn't working topic-any labels Jan 12, 2025
@jorenham
Copy link
Collaborator Author

And the weirdest thing is that in this example, it occurs twice:

from typing import Generic, TypeVar

T = TypeVar("T", bound=int | slice)  # E: no-any-explicit

class A(Generic[T]): ...  # <no error>
class B(A[T]): ...  # E: no-any-explicit

So with A it doesn't report an error, but with B it does?

@jorenham
Copy link
Collaborator Author

For a real life example, see e.g. optype/numpy/_to.py, which doesn't even import Any, yet there are 62 no-any-explicit errors reported, forcing me to use # mypy: disable-error-code="no-any-explicit".

@KotlinIsland
Copy link
Owner

I'm guessing this is because the type parameters of slice default to Any. But I don't see why such an implicit Any should be considered as explicit.

so this is more about understandability? or would you not want an error here at all?

@jorenham
Copy link
Collaborator Author

I don't think it's useful in this case, because the Any is out of your control. I also don't think that it's useful to report the same error about the same Any on multiple occasions. Given the name of the error, I expected it to only be reported once I explicitly write "Any", so that I can actually see that it's there.

I might be wrong here, but I thought that that's also the way that bpr's reportExplicitAny works 🤷🏻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working topic-any upstream
Projects
None yet
Development

No branches or pull requests

2 participants