Run Pyright for CI Checks

[Max Muoto]

Is your feature request related to a problem? Please describe.
Pyright is effectively the default type-checker for Python in VSCode, through Pylance. It's likely many Instructor users have Pylance/Pyright enabled through VSCode, which can lead to a variety of type-checking errors in places where Pyright is stricter than MyPy

How is Pyright stricter than MyPy?
Often times instructor will deal with generic classes without passing parameters, MyPy is usually fine with this, just inferring Any for anything not filled in. Let's take this example:

from typing import Callable, reveal_type
    
def foo(create: Callable):
    reveal_type(create)

For MyPy, def (*Any, **Any) -> Any is revealed, while for Pyright create: (...) -> Unknown is revealed. As a result, those with stricter type-checking settings on will get run into errors whenever Instructor, does something like this, usually with just Callable or Awaitable. This same principle also principle also applies for dict, list, and other ggenerics. dict == dict[unknown, unknown], etc.

Describe the solution you'd like
Additionally run Pyright, alongside MyPy in CI checks, and fix existing Pyright violations

Fixing existing violations

I think fixing most existing issues wouldn't be overly difficult, in my cases it would just be providing more context, Callable -> Callable[..., Any], dict -> dict[str, Any], etc., however Pyright does catch typing errors that MyPy hasn't.

With the "standard" as the type-checking mode on, it catches about 40 errors, which I think is pretty doable, there might need to be some ignores in places with Instructor is dealing with third-party libraries that could be better typed, but I think there will be a lot of valuable in the primary API being fully compliant with Pyright.

Possible issues

I would say one partial issue is that Pyright actually has far fewer bugs, which means we'll have to be careful about writing code that is compatible across both. I would in the long-term, you could just run Pyright.

MyPy currently sits at about 2.7K issues, with Pyright at 30. There's also a repo going over the issues said issues in MyPy, to ensure they weren't present in Pyright: https://github.com/erictraut/mypy_issues

I would argue for the most accurate type-checking ossible, and so being able to lean in typing that's broken in MyPy, but works in Pyright, you could just run the later long-term. But for the sake of getting the most compatible across users, I think think running both would suffice, and add typing ignores where there is some key difference across the two.

Pyright also does an excellent job of staying on top of each Python version. Unlike MyPy, all 3.12 features are supported, as well as some of the upcoming 3.13 features through typing_extensions. It's possible to starting making use of these, even on earlier versions of Python through typing_extensions, so having earlier support can be valuable.

[Max Muoto]

@jxnl If this is something you're interested in, happy to put up a PR fixing these Pyright issues, and adding the checks.

[Jason Liu]

i this a replacement for mypy... our mypy is pretty broken rn...

[Max Muoto]

i this a replacement for mypy... our mypy is pretty broken rn...

Yeah, it's a MyPy alternative.

[Jason Liu]

lets try it since mypy is broken right now!

[Max Muoto]

lets try it since mypy is broken right now!

Sounds great, I'll get to work on a PR!