Typing information obscured to static analyzers

[GinoMan]

Expected Behavior

In an editor that supports static analysis, the analyzer should be able to recognize the types used in the declarative syntax as valid, but it does not, nor can any sort of intellisense provide information about available options. This is because the types are automatically generated into the class. Adding type stubs would fix the issue.

Python code

from flask import Flask
from flask_sqlalchemy import SQLAlchemy
...
Db = SQLAlchemy()
App = Flask(__name__, ...)
...
Db.init_app(App)
...
class User(Db.Model):
	id = Db.Column(Db.Integer, primary_key=True)
	username = Db.Column(Db.String(100), unique=True)
	password_hash = Db.Column(Db.String(500))

VSCode Config

{
...
    "python.languageServer": "Pylance",
...
}

Actual Behavior

In the code above, Db.Model, Db.Integer, Db.Column, and Db.String are all marked as errors. The specific message in Pylance in VSCode for example is:

Cannot access member "String|Model|Column|Integer" for type "SQLAlchemy"
Member "String|Model|Column|Integer" is unknown Pylance (reportGeneralTypeIssues)

The problem isn't necessarily with the static checker. Opening the init.py for flask_sqlalchemy shows that there really are no members by that name. Instead they're dynamically determined by the code on line 66-70. Plus, since they're dynamically determined, the type checker cannot know ahead of time what is supported. Creating subs in the SQLAlchemy class would likely fix the issue.

Installing this package for example caused "Db.Model" to become recognized by Pylance. I'm not super familiar with stubbing in python but I suspect something similar could be done for the other symbols in SqlAlchemy and SqlAlchemy.orm (see also this issue for pylance).

Environment

• Python version: 3.8.3
• Flask-SQLAlchemy version: 2.4.4
• SQLAlchemy version: 1.3.18
• VSCode version: 1.47.3

[davidism]

While I am planning to add typing to libraries like this one, this specific request is essentially impossible. We assign the entire sqlalchemy namespace into the db object, it would be unmaintainable to add in annotations for every value, especially since it wouldn't be able to take advantage of any annotations that SQLAlchemy itself might add.

Since the db attributes are literally the same as the SQLAlchemy objects in all but a few special cases, you can use those imports directly if you need better insight. Otherwise, you'll have to accept that libraries that take advantage of dynamic features will have less about support.