Evaluating Pyright vs Mypy for preexisting codebase with too-dynamic model base class

[jrheard-seesaw]

Hi! I'm about to make a pitch for introducing a type checker into a decently-sized preexisting Python codebase. I was going to go with Mypy because I've used it before, but am considering Pyright too.

The main technical obstacle I'm expecting to face with this rollout has to do with the base class the codebase uses for its models. It's meant to be used like this:

class FooModel(BaseModel):
    def __init__(self) -> None:
        super().__init__()

        self._db_name = KeywordType()
        self._db_is_something = BoolType()
        self._db_a_set = SetType()
        self._db_an_int = IntegerType()
        self._db_a_float = FloatType()
        self._db_a_dict = JSONType()
        self._db_long_string = TextType()
        self._db_a_list = ListType()

        self.add_properties()


x = FooModel()

# The following lines of code work fine at runtime, but any sane type checker will complain about them.
x.name = "foo"
print(x.is_something)
sorted(x.a_list)
print(x.a_dict["foo"])
x.a_set.add(5)

There is a ton of code that looks like this. It's not unheard-of for models to have dozens of ._db fields. Replacing/refactoring this system is not an option; I need to come up with a strategy to allow for a type checker to work on code like this.

On the Mypy side, I'm hoping that it'll be possible to write a plugin to make code like this type check. It'll be a pain to have to write a plugin and keep it up to date with new mypy versions and make it available to multiple repos that use this model system, but it seems potentially possible. I haven't looked into this in earnest yet, though.

Since Pyright doesn't support plugins, I'm expecting that Pyright won't be an option for this codebase. I've heard great things about it, though, so I wanted to ask here: is it possible for us to use Pyright in a codebase that has lots and lots of code that looks like the snippet above? If so, how can I get that code to type check?

(I guess another option would be to find a way to declare that these models are effectively Any at type checking time and quit while I'm ahead. Is that what you would do if you were me?)

[erictraut]

Pyright is a standards-based type checker, and it supports all of the capabilities of the Python static type system. Let's see if there's a way to meet your needs within the capabilities of the type system.

What library are you using here? I'm not sure where the symbols BaseModel, KeywordType, etc. are coming from. Are they exported from Sqlalchemy? FastAPI? Pydantic? Some other ORM?

[jrheard-seesaw]

It's essentially an in-house ORM in a closed-source codebase; it's not derived from anything else, the BaseModel class inherits from nothing and doesn't e.g. import/use any third-party ORM lib. I'm happy to speak generally about its overall behavior and answer any questions that could be helpful for this discussion, but can't provide any concrete code to look at, sorry!

[erictraut]

Without more details about how the library works, it's difficult to offer any concrete suggestions, but I can offer some general ideas that might be useful to you.

1. You can make BaseModel derive from Any (conditionally, if TYPE_CHECKING is True). This will tell static type checkers to allow access (read or write) to any additional attributes on BaseModel subclasses and treat these attributes as Any.
2. Similarly, you could define a __getattr__ method in the BaseModel class (conditionally, if TYPE_CHECKING is True). This gives you a bit more control than the previous option because you can overload it for specific attributes (using Literal names). It also allows you to make any additional attributes read-only (assuming you don't also define a __setattr__ method).
3. If your model definitions are isolated in their own modules, separate from the code that uses these models, you could write a script that generates corresponding ".pyi" (stub) files for your models. You could run this script whenever a model changes, and then check in the resulting ".pyi" files, which would live alongside their corresponding ".py" files. This is similar to the technique that's often used for protobuf definitions. (See https://github.com/nipunn1313/mypy-protobuf.)

[jrheard-seesaw]

Thank you! I'll investigate these options. Much appreciated!