Goal of this PR is to type orm's Query objects. This will allow to type-check stuff like:

session.query(Employee)  # -> Query[Employee]
session.query(Employee).get(123)  # -> Employee
session.query(Employee, Invoice)  # -> Query[Tuple[Employee, Invoice]]
session.query(Employee, Invoice).all()  # -> List[Tuple[Employee, Invoice]]

- repo: https://github.com/pre-commit/mirrors-mypy
   rev: v0.782
   hooks:
     - id: mypy
       args: [--strict-optional, --ignore-missing-imports, --follow-imports=skip]
       additional_dependencies:
         - pydantic
         - sqlalchemy-stubs

Currently my .pre-commit-config.yaml looks like the above. However, adding sqlalchemy-stubs to the additional_dependencies doesn't do anything to change the behaviour. Adding sqlmypy to setup.cfg works just fine however.

If someone on the team or @asottile can help, that'd be much appreciated.

Upgrading to mypy 0.930 triggered the following INTERNAL ERROR issue:

% mypy --config-file pkg/tsa-repo-db-client/setup.cfg -p tsa.repo.db --show-traceback
***/pkg/tsa-repo-db-client/tsa/repo/db/model.py:11: error: INTERNAL ERROR -- Please try using mypy master on Github:
https://mypy.readthedocs.io/en/stable/common_issues.html#using-a-development-mypy-build
Please report a bug at https://github.com/python/mypy/issues
version: 0.930
Traceback (most recent call last):
  File "mypy/semanal.py", line 5132, in accept
  File "mypy/nodes.py", line 1140, in accept
  File "mypy/semanal.py", line 2110, in visit_assignment_stmt
  File "mypy/semanal.py", line 2392, in apply_dynamic_class_hook
  File "***/miniconda3/envs/tsa37/lib/python3.7/site-packages/sqlmypy.py", line 203, in decl_info_hook
    obj = ctx.api.builtin_type('builtins.object')
AttributeError: 'SemanticAnalyzer' object has no attribute 'builtin_type'
***/pkg/tsa-repo-db-client/tsa/repo/db/model.py:11: : note: use --pdb to drop into pdb

Considering the announcement in https://github.com/python/mypy/issues/6617 , I assume this should be solved here ...

Workaround: keep mypy pinned on version 0.921

Right now relationship(uselist=True) uses typing.Iterable, which breaks most of our code.

Relationship configuration is described in greater detail here: https://docs.sqlalchemy.org/en/13/orm/collections.html

Right now this PR just replaces typing.Iterable with list.

What I plan to do in this PR:

• [x] default to list when using uselist=True
• [ ] use collection_class argument to customize collection class if present (simple type)

What can be done later:

• support dynamic loader and query_class parameters (when #81 gets accepted)
• support dict-like collections (attribute_mapped_collection, column_mapped_collection, mapped_collection)

The official SQLAlchemy documentation for the column type Numeric says:

This type returns Python decimal.Decimal objects by default, unless the Numeric.asdecimal flag is set to False, in which case they are coerced to Python float objects.

https://docs.sqlalchemy.org/en/13/core/type_basics.html#sqlalchemy.types.Numeric

Currently this is specified in sqltypes.pyi as TypeEngine[float] but by default the inner data type for Numeric should be Decimal, not float. That would be more in line with

• what the SQLAlchemy documentation says.
• how SQLAlchemy actually behaves.

The current approach reports typing errors even though the code is correct (due to the float/Decimal confusion) . Example to reproduce:

from decimal import Decimal
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy import Column, Integer, Numeric

Base = declarative_base()


class Transaction(Base):
    __tablename__ = 'transactions'
    id = Column(Integer, primary_key=True)
    amount = Column(Numeric, nullable=False)


user = User(id=42, amount=Decimal(42))

This code is 100% correctly typed, but since the sqlalchemy-stubs use float instead of Decimal we receive a typing-error message that we shouldn't get:

mypy-sa-test.py:14: error: Incompatible type for "amount" of "User" (got "Decimal", expected "float")

:sparkles: Type relationship as list.

Currently, the plugin types relationships with uselist as Iterable[X], but these relationships actually expose a list with list semantics, including .append(), assignments, etc.

This PR updates the plugin to type those relationships with List[X] instead of Iterable[X].

Ref: https://docs.sqlalchemy.org/en/13/orm/relationship_api.html#sqlalchemy.orm.relationship.params.uselist

Ref of usage with assignment: https://docs.sqlalchemy.org/en/13/orm/tutorial.html#working-with-related-objects Ref of usage with append: https://docs.sqlalchemy.org/en/13/orm/tutorial.html#building-a-many-to-many-relationship

Note: I'm by no means expert in mypy internals and its plugins, I'm not 100% sure the usage of ctx.api.named_generic_type('builtins.list', [new_arg]) is correct here, but I see that seems to be how it's used by mypy: https://github.com/python/mypy/blob/master/mypy/plugins/ctypes.py#L158

First, thanks for making these stubs and plugin! It works great. I'm using it with Pyright and that gives me autocompletion in VS Code for SQLAlchemy stuff, that never worked before. :sparkles:

This PR includes a reduced version of the changes by @rafales in #81 .

I removed the plugin method hook and its tests to reduce the scope of the PR, to make it easier to manage and merge, as just the type annotations are a great improvement.

I applied @ilevkivskyi 's code review from that PR here as well.

There were some unresolved questions/discussions in that PR, so I removed any changes related to those sections.

My objective is just to reduce the scope of the changes to the minimum that would be easily acceptable and postpone any additional improvement for future PRs.

Hello! Thanks for building this plugin and stubs! It's great to see more support for type-checked Python.

We hit a wall and needed to #type: ignore our ForeignKeyConstraint calls to get them to pass type checking. We found that a fix had been merged a couple months ago (#56), but is not yet released. We were deciding between either submoduling this repo so we could use the fix which is on master or just #type: ignoreing it, neither is really great. Could you guys please put out a v0.2 release for this library so we can clean that up? Thanks :)

when running mypy on my project, I get this error: Error importing plugin sqlmypy

When debugging a little bit, the problem seems to be here:

    def get_dynamic_class_hook(self, fullname: str) -> CB[DynamicClassDefContext]:
  File "/usr/lib/python3.5/typing.py", line 546, in __getitem__
    "Cannot subscript an existing Union. Use Union[u, t] instead.")
TypeError: Cannot subscript an existing Union. Use Union[u, t] instead.

We currently can only detect declarative bases defined using @as_declarative, a plugin for detecting declarative_base() depends on https://github.com/python/mypy/issues/5508

Hello, With the latest release of mypy and the master branch of sqlalchemy-stubs, this code causes mypy to raise a "error: Unexpected keyword argument "name" for "User"" Is there smth I can do to avoid these errors ?

from sqlalchemy import CheckConstraint, Column, Integer, String
from sqlalchemy.ext.declarative import as_declarative

@as_declarative()
class Base:
    pass


class User(Base):
    __tablename__ = 'users'
    id = Column(Integer, primary_key=True)
    name = Column(String)


user = User(name="xx")

error: Unexpected keyword argument
"overlaps" for "RelationshipProperty"  [call-arg]

I get this error when running typing on code that includes the overlaps keyword on a relationship.

for this sort of code:

user = UserModel.query.filter_by(username="awesomeuser").first()
db.session.delete(user)  # type: ignore, until now
db.session.commit()

not sure if it's a new issue in some version of sqlalchemy. i'm on SQLAlchemy-1.4.42 and Flask-SQLAlchemy-3.0.2.

https://docs.sqlalchemy.org/en/14/orm/extensions/declarative/

Changed in version 1.4: The vast majority of the Declarative extension is now integrated into the SQLAlchemy ORM and is importable from the sqlalchemy.orm namespace.

Using the old location (ext.declarative) gives a deprecation warning when SQLALCHEMY_WARN_20 enabled.

There are no hints in PyCharm for models, which inherit declarative base from another module. Here is example:

# base.py
import re

from sqlalchemy import Column, Integer, DateTime
from sqlalchemy.ext.declarative import declared_attr
from sqlalchemy.sql import func
from sqlalchemy.ext.declarative import declarative_base


class Base:
    @declared_attr
    def __tablename__(cls):
        return cls.__name__.lower()

    id = Column(Integer, primary_key=True, index=True)
    created_at = Column(DateTime(timezone=True), nullable=False, server_default=func.now())


Base = declarative_base(cls=Base)

# models.py
from base import Base
from sqlalchemy import Integer, String, Column


class SomeModel(Base):
    id = Column(Integer, primary_key=True)
    name = Column(String)
    description = Column(String)

In the sqlalchemy version 1.4, the method isnot was renamed to is_not, and the old method was left for backward compatibility.

(see https://docs.sqlalchemy.org/en/14/core/sqlelement.html#sqlalchemy.sql.expression.ColumnOperators.is_not)

However, if one try to use is_not on the column expression

(something like:

...
.where(and_(pch_alias.c.New_Id.is_not(None))))

) then one gets following warning in mypy:

error: "Column[Any]" has no attribute "is_not" However, if one is using older isnot construct, then mypy produces no warning.

As is_not now is a recommended method, I think stubs should function with it without warnings.