Flask-SQLAlchemy and Mypy

[tungol]

I'm opening this discussion for workaround to the previous discussed issues using mypy with flask-sqlalchemy:

#1327
#1186

In #1327, @fhd documented the workaround:

from typing import TYPE_CHECKING
...
if TYPE_CHECKING:
    from flask_sqlalchemy.model import Model
else:
    Model = db.Model

But he noted that this causes errors when using keyword arguments to the model classes. I spent a little while figuring this out, so I wanted to share my solution for that issue:

When you don't define an __init__ method on your class, it ends up with sqlalchemy.orm.decl_base._declarative_constructor as the __init__ method, which is then additionally wrapped by SQLAlchemy instrumentation functions. If you'd like to use keyword arguments, you should define a custom __init__ method which wraps this function:

from typing import TYPE_CHECKING
from flask_sqlalchemy import SQLAlchemy
from sqlalchemy.orm.decl_base import _declarative_constructor

db = SQLAlchemy()

if TYPE_CHECKING:
    from flask_sqlalchemy.model import Model
else:
    Model = db.Model


class Thing(Model):
    __tablename___ = "things"
    name: Mapped[str]

    def __init__(self, *, name: str) -> None:
        _declarative_constructor(self, name=name)

With that, you can specify whatever mix of required and optional keywords you like. The signature for _declarative_constructor is: _declarative_constructor(self: Any, **kwargs: Any) -> None, so using kw-only args ensures that the interface is the same. Now Mypy will understand what kw-args are allowed for your class.

[davidism]

Your idea, as with the others, is not correct. from flask_sqlalchemy.model import Model is not a SQLAlchemy declarative base class, it's the plain Python base class, so you're not getting any of SQLAlchemy's type checking support. Defining __init__(specific, args, names) defeats the entire purpose of SQLAlchemy's **kwargs support and requires doing so for every model individually.

Flask-SQLAlchemy-Lite is available to transition to. It manages engine config and sessions, but otherwise is plain SQLAlchemy, meaning all typing works.

[tungol]

I understand that it's not formally correct, and obviously creating the __init__ functions is extra work. I just wanted to share it here, because figuring out the explicit __init__ functions took me a bit and was an improvement in the typing of my application. Doing this caught a couple small issues for me once it was done. I'm not sure what SQLAlchemy type checking support I'm missing, because this method does provide quite a lot of good typing. I'm sure there's something, as you say, but it certainly doesn't feel like I'm not getting any of it based on how many problems mypy has caught for me.

At any rate, I know you're a bit of sick of the topic (and reasonably so) and I didn't mean to pile on. I didn't know about Fask-SQLAlchemy-Lite, so I do appreciate the link there. Thanks for all your work!