-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash on numtype numpy stubs package related to property #18764
Comments
Partially minimised repro:
|
Oh well, I was wandering why some code paths (inconsistently) expose settable property type as |
@hauntsaninja could you please check that #18774 fixes the original crash? (I have a very minimalist example in the tests.) |
Fixes #18764 There are two things important to understand this PR: * First, mypy has a performance optimization - we store decorator/overload type during semantic analysis in certain "trivial" situations (to avoid deferrals). Otherwise, we infer the type of decorated function or an overload variant during type checking. * Second, for settable properties we store getter type in two places, as a `Var.type` of getter (as a decorator), and also in overall `OverloadedFuncDef.type`. The latter is ugly, but unfortunately it is hard to get rid of, since some code in multiple plugins rely on this. It turns out there are _three_ inconsistencies in how these two things interact (first one causes the actual crash): * For trivial settable properties (i.e. without extra decorators) when we store the type in `semanal.py` we only store it the second way (i.e. as `OverloadedFuncDef.type`). * For non-trivial settable properties (where getter and/or setter are themselves decorated), we only set the inferred type the first way (as `Var.type`). * When inferring setter type (unlike getter, that is handled correctly) we actually ignore any extra decorators (this is probably quire niche, but still inconsistent). Essentially I simply remove these inconsistencies.
I can confirm that latest mypy main (af5186e) now indeed runs without crashing on numtype (8598dc9): Thanks, @ilevkivskyi and @hauntsaninja! |
numtype commit 864cda2
Seems similar to #18648 cc @ilevkivskyi
The text was updated successfully, but these errors were encountered: