Complete SQLAlchemy inline pep484 typing #6810
Comments
CaselIT
added
big job
|
We should try https://github.com/ambv/retype/ |
|
Federico Caselli referenced this issue: Properly type _generative https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/3423 |
Good new is that pylance likes it and copies over the singature and everything. Bad news is that mypy does not support this yet python/mypy#8645 Other minor bad news is that non_generative is not typed. I've tried using a protocol like the one in the comment but the signature is not ported over by pylance, so it's probably best to just live without it to have the correct signature. notes from mike: these three decorators are at the core of getting the library to be typed, more good news is that pylance will do all the things we like re: public_factory, see microsoft/pyright#2758 (comment) . For @_generative, we will likely move to using pep 673 once mypy supports it which may be soon. but overall having the explicit "return self" in the methods, while a little inconvenient, makes the typing more straightforward and locally present in the files rather than being decided at a distance. having "return self" present, or not, both have problems, so maybe we will be able to change it again if things change as far as decorator support. As it is, I feel like we are barely squeaking by with our decorators, the typing is already pretty out there. Change-Id: Ic77e13fc861def76a5925331df85c0aa48d77807 References: #6810
|
Mike Bayer has proposed a fix for this issue in the main branch: initial reorganize for static typing https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/3447 |
|
also there's the issue of replacing existing sqlalchemy-stubs packages in type checkers and it's suggested we use a "positive" masking approach, as a "negative" uninstall approach is not supported by type checkers that bundle the stubs: microsoft/pylance-release#840 (comment) |
|
Mike Bayer has proposed a fix for this issue in the main branch: WIP for ORM typing https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/3495 |
zzzeek
added
typing
|
current goals are:
|
|
Step 4. was something that I meant to suggest since we now are guaranteed to always have at least py3.6 does it make sense as a separate change? |
|
im going to try it now as its own thing, not including declarative, which probably also needs to be its own thing |
|
I think we might want to skip declarative as the DeclarativeMeta class also intercepts class-level setattr and delattr events. in that sense we are still using metaclass-only features. i have all the internal stuff off of metaclasses with one small exception in the ORM, will keep it at that. |
|
Mike Bayer referenced this issue: remove internal use of metaclasses https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/3499 |
All but one metaclass used internally can now be replaced using __init_subclass__(). Within this patch we remove: * events._EventMeta * sql.visitors.TraversibleType * sql.visitors.InternalTraversibleType * testing.fixtures.FindFixture * testing.fixtures.FindFixtureDeclarative * langhelpers.EnsureKWArgType * sql.functions._GenericMeta * sql.type_api.VisitableCheckKWArg (was a mixture of TraversibleType and EnsureKWArgType) The remaining internal class is MetaOptions used by the sql.Options object which is in turn currently mostly for ORM internal use, as this type implements class level overrides for the ``+`` operator. For declarative, removing DeclarativeMeta in place of an `__init_subclass__()` class would not be fully feasible as it would break backwards compatibility with applications that refer to this class explicitly, but also DeclarativeMeta intercepts class-level attribute set and delete operations which is a widely used pattern. An option for declarative base to use `__init_subclass__()` should be provided but this is out of scope for this particular change. Change-Id: I8aa898c7ab59d887739037d34b1cbab36521ab78 References: #6810
|
Mike Bayer referenced this issue: Initial ORM typing layout https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/3495 |
Status as of 2023-02
Most of the library is typed, but some modules/packages that are still work in progress.
Modules / packages that still require work
sqlalchemy.dialectspopular apimssql- missing most/all typesmysql- missing most/all typesoracle- missing most/all typespostgresql- missing most/all typessqlite- missing most/all typessqlalchemy.enginecursor- passes omitting non-typed functions - internal moduledefault- passes omitting non-typed functions - internal modulesqlalchemy.extdeclarative.extentions- missing most/all types - legacybacked- missing most/all types - legacycompiler- missing most/all types - popular apiindexable- missing most/all typesinstrumentation- missing most/all typesorderinglist- missing most/all typesserializer- missing most/all types - legacysqlalchemy.ormbulk_persistence- missing most types - internal modulecollections- missing most types - internal modulecontext- missing most types - internal moduledependency- missing most types - internal moduledynamic- missing most types - internal moduleevaluator- missing most/all types - internal moduleinstrumentation- missing some types - internal moduleloading- missing most types - internal modulepersistence- missing most types - internal modulestrategies- missing most types - internal modulestrategies- missing most types - internal moduleunitofwork- missing most types - internal moduleutil- missing most types - internal modulewriteonly- missing most types - internal modulesqlalchemy.sqlbase- missing most types - internal modulecompiler- missing most types - internal modulecrud- missing most types - internal moduleddl- missing most types - internal modulefunctions- missing most types - internal modulelambdas- missing most types - internal modulenaming- missing most types - internal moduleroles- missing most types - internal moduletraversals- missing most types - internal moduleutil- missing most types - internal moduleThe text was updated successfully, but these errors were encountered: