5 ms·

I appreciate that argument but some codebases are heavily reliant on “magic” libraries like SQLAlchemy. The SQLAlchemy mypy plugin helps a lot. Well, at least w

I appreciate that argument but some codebases are heavily reliant on “magic” libraries like SQLAlchemy. The SQLAlchemy mypy plugin helps a lot. Well, at least with SQLAlchemy 1.4; dunno if 2.0 needs the plugin

solarkraft 4y ago
I ran into this issue recently. 2.0 will not need the plugin and work with any Python type checker! So much so that the plugin is already somewhat deprecated.
- fbdab103 4y ago
  That is most welcome news. I use VSCode, and the amount of unparseable magic makes working with the library more annoying than I would like.
  - solarkraft 4y ago
    Yup. Lots of casting or # type: ignore for now. Here's an official bit about the new types: https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html#new-typing-support-in-core-and-orm-stubs-extensions-no-longer-used https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...
zzzeek 4y ago
we've worked very heavily with the pyright developers directly on some aspects of SQLAlchemy 2.0, namely the new dataclasses feature : https://docs.sqlalchemy.org/en/20/orm/dataclasses.html#declarative-dataclass-mapping https://docs.sqlalchemy.org/en/20/orm/dataclasses.html#decla... that said, the codebase primarily targets mypy for internal type checking; we tried targeting both tools simultaneously but there were great differences between both tools, which tended towards doubling our workload in getting everything to pass typing fully. In more than one case there were areas where the two tools would mutually disagree with each other, making "correct" typing impossible. This was some iterations back and mypy has had a lot of good releases since then (pyright has had many more, obviously). when typing a large codebase, there are invariably lots of areas where you just need to "type: ignore" or otherwise do some non-ideal workarounds. it's in that area that trying to target more than one type checker at once gets to be really difficult.
- goodoldneon 4y ago
  Sweet! I might have to work on upgrading us from 1.4 to 2.0

solarkraft 4y ago

I ran into this issue recently. 2.0 will not need the plugin and work with any Python type checker! So much so that the plugin is already somewhat deprecated.

fbdab103 4y ago
That is most welcome news. I use VSCode, and the amount of unparseable magic makes working with the library more annoying than I would like.
- solarkraft 4y ago
  Yup. Lots of casting or # type: ignore for now. Here's an official bit about the new types: https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html#new-typing-support-in-core-and-orm-stubs-extensions-no-longer-used https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html...

zzzeek 4y ago

we've worked very heavily with the pyright developers directly on some aspects of SQLAlchemy 2.0, namely the new dataclasses feature : https://docs.sqlalchemy.org/en/20/orm/dataclasses.html#declarative-dataclass-mapping https://docs.sqlalchemy.org/en/20/orm/dataclasses.html#decla... that said, the codebase primarily targets mypy for internal type checking; we tried targeting both tools simultaneously but there were great differences between both tools, which tended towards doubling our workload in getting everything to pass typing fully. In more than one case there were areas where the two tools would mutually disagree with each other, making "correct" typing impossible. This was some iterations back and mypy has had a lot of good releases since then (pyright has had many more, obviously). when typing a large codebase, there are invariably lots of areas where you just need to "type: ignore" or otherwise do some non-ideal workarounds. it's in that area that trying to target more than one type checker at once gets to be really difficult.

goodoldneon 4y ago
Sweet! I might have to work on upgrading us from 1.4 to 2.0