New "verifytypes" functionality

[erictraut]

I'm planning to rewrite the "--verifytypes" functionality in pyright, and I'm looking for feedback from those of you who have used the feature in its current form.

What is working, and what isn't?

Here's a couple of things I'm considering changing:

1. Rather than outputting missing type details only for public symbols, output missing type details for all symbols that are transitively referenced by public symbols. This will eliminate the large, nested, and difficult-to-read error messages that are output today.
2. Allow verifytypes to be enabled in the language server so missing type errors are reported in place in the editor and updated live as changes are made. This will require incrementally updating the verifytypes report when changes are made.

[Dr-Irv]

Aside from what I suggested in #1395 , it would be useful to understand a "root cause". So right now, if you have classes A, B, and C that all depend on some class X, and X is incomplete from a verifytypes perspective, you see the report for X multiple times. Figuring out that X is that root cause is not easy with the current output. I wrote a script to parse the JSON and counted how many times each message appears, which then helps direct you to that class X that is the root cause.

Ideally, that kind of report would be available from the veriftytypes option.

[erictraut]

Yeah, that's what I have in mind in #1 above. In your example, X would be listed separately in the report, and A, B, and C would simply indicate that they are incomplete because they rely on X.

It sounds like you would also be interested in a "reference count" for a type? For example "Type X was referenced 1045 times in the public interface"? That would presumably allow you to prioritize changes.

[Dr-Irv]

Yes, a reference count would be useful. But more of a kind that says "Type X was referenced 1045 times in the public interface and has 3 issues". No need to list the 1045 references if type X has no issues.

[vemel]

Is it possible to inherit type annotations from parent classes?
Also, untyped 3rd party classes are reported as unknown.

from untyped_lib import UntypedClass

class A:
   name: str = "A"
   
class B:
   name = "B" # pyright complains about unknown type in B.name, even though it is str
   untyped: UntypedClass = UntypedClass() # reported as unknown event with `--ignoreexternal` flag
   untyped_any: Any = UntypedClass() # works, but you lose auto-complete and type checking

[erictraut]

No, the type of a symbol declared in a child class is not inherited from parent class. If the child class is part of the public interface for your library, it needs to declare the types of its own symbols. There are situations where a child class can have a narrower (more specific) type than its parent. Of course, if it's a private symbol within the child (e.g. _name), then it doesn't need to have a type declaration.

If you are exposing classes imported from other libraries, they need to be typed also. Please work with the maintainers of that library to get types in place. If you want to focus initially on annotating your internal types, you can use the --ignoreexternal command-line option to ignore the types that are imported from other libraries. But if you want users to have a great experience using your library, it's important for all classes that are part of your public interface to have type information regardless of where those classes are defined and implemented.

Most library maintainers I've talked to have been receptive to adding types. The motivation is there. They just need some guidance and tooling to make it happen. If we all do our part, we can make it happen relatively quickly!

[Dr-Irv]

It would be useful if there was an option to turn off the "missing docstrings" check.

[erictraut]

Thanks for all the feedback. I've rewritten the type verifier functionality. See this issue for details.