Open nipunn1313 opened 4 years ago
@ddfisher helped me debug something and recommended this.
Which typeshed warnings do you mean?
er I mean mypy typeshed errors.
In my case, I was co-developing my own project (mypy-protobuf) and typeshed using --custom-typeshed-dir
In typeshed, I used a type (Generic
specifically) and forgot to import it from typing import Generic
.
When type-checking my own code, it silently switched Generic
to Any
. My understanding is that this was an intentional decision to hide errors within typeshed.
I was able to catch the issue by running the typeshed tests, but for convenience when doing this co-developing, it would be nice to see those errors when mypy-ing my own project with this custom-typeshed-dir flag.
I like this idea. It's also possible that we'll start reporting errors in typeshed always, after we've switched to modular typeshed. (We may also have to rename --custom-typeshed-dir
.)
Please note that typeshed might use less strict options than other projects. For example, Bad example, but the point stands.--warn-return-any
would raise lots of warnings in typeshed.
One possible solution are per-directory mypy config files that override other configuration options.
Ah a good point. A potentially simpler option would be to use a fixed set of strictness options for typeshed. Anyway, this sounds a bit complicated, so I'm removing the good-first-issue label.
Now that we have modular typeshed (yay!!), I think it would be good to revisit this. Setting fixed options for typeshed seems like a very good option.
I'm not sure if that would be easy though, we'd have to fake per-module flags or something similar.
When using
--custom-typeshed-dir
, I'm intentionally indicating that I'm using my own edited version of typeshed. It would be nice for typeshed warnings to be surfaced under these conditions.