]> git.ipfire.org Git - thirdparty/sqlalchemy/sqlalchemy.git/commit
Re-infer statements that got more specific on subsequent pass
authorMike Bayer <mike_mp@zzzcomputing.com>
Mon, 19 Apr 2021 22:03:12 +0000 (18:03 -0400)
committerMike Bayer <mike_mp@zzzcomputing.com>
Tue, 20 Apr 2021 17:05:49 +0000 (13:05 -0400)
commit0e1a011aa3091aa2d6d95b269ff6da518db8e1a3
treef9c90c014aba42801f671455f812d303c2cf2d80
parenta58c99977eafc5f69a3e37f9ddcc328698e7fe1e
Re-infer statements that got more specific on subsequent pass

Fixed issue where mypy plugin would not correctly interpret an explicit
:class:`_orm.Mapped` annotation in conjunction with a
:func:`_orm.relationship` that refers to a class by string name; the
correct annotation would be downgraded to a less specific one leading to
typing errors.

The thing figured out here is that after we've already scanned
a class in the semanal stage and created DeclClassApplied,
when we are called again with that same DeclClassApplied, for this
specific kind of case we actually now have *better* types than
we did before, where the left side that looked like
List?[Address?] now seems to say
builtins.list[official.module.Address] - so let's take the
right side expression again, this time embedded in our
Mapped._empty_constructor() expression, and run the infer
all over again just like mypy would.   Just not setting the
"wrong" type here fixed the test cases but by re-applying the
whole infer we get the correct Mapped[] on the left side too.

Fixes: #6255
Change-Id: Iafe7254374f685a8458c7a1db82aafc2ed6d0232
doc/build/changelog/unreleased_14/6255.rst [new file with mode: 0644]
lib/sqlalchemy/ext/mypy/apply.py
lib/sqlalchemy/ext/mypy/decl_class.py
lib/sqlalchemy/ext/mypy/infer.py
setup.cfg
test/ext/mypy/files/relationship_6255_one.py [new file with mode: 0644]
test/ext/mypy/files/relationship_6255_three.py [new file with mode: 0644]
test/ext/mypy/files/relationship_6255_two.py [new file with mode: 0644]
test/ext/mypy/test_mypy_plugin_py3k.py