You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
0.990 reports error for function with body that is just ellipsis #14048
This was an intentional change in 0.990 and the special casing for ... bodies was mostly removed (#13729). The documentation seems to be now out of date.
Now you need --allow-empty-bodies if you want old behavior
I'm unsure if I want the old behavior🤔 Actually I was ever in doubt if the way I used such ... stubs was good practice. If you have a minute left, would you consider this pseudo code:
classFooStub:
# Serves as means to check calls to use_generated_foo() with mypydefbar() ->int:
...
classGeneratedFoo(RuntimeAttrGen, FooStub):
# Attributes made available at runtime, according to external spec.# I control the spec and therefore know what methods and attributes will be available, # but can't hardcode implementations here.passdefuse_generated_foo(x: FooStub)
x.bar()
Would you recommend another approach for type checking such runtime-determined types? E.g., I'd rather avoid deriving from FooStub in favor of structural subtyping. But then I don't know how to associate GeneratedFoo with attributes and methods as in FooStub.
IIUC the situation, my personal preference would be to replace ... with raise AttributeNotGeneratedError. This way if empty stub is used accidentally, you will know immediately, instead of discovering random None somewhere down the call stack.
Activity
[-]0.990 reports [/-][+]0.990 reports error for function with body that is just ellipsis[/+]JukkaL commentedon Nov 9, 2022
This was an intentional change in 0.990 and the special casing for
...bodies was mostly removed (#13729). The documentation seems to be now out of date.JukkaL commentedon Nov 9, 2022
cc @ilevkivskyi
ilevkivskyi commentedon Nov 9, 2022
Yep, I will update the docs. Now you need
--allow-empty-bodiesif you want old behavior (or disable empty-body error code in your mypy config)haxtibal commentedon Nov 9, 2022
Thank's for clarifying.
I'm unsure if I want the old behavior🤔 Actually I was ever in doubt if the way I used such
...stubs was good practice. If you have a minute left, would you consider this pseudo code:Would you recommend another approach for type checking such runtime-determined types? E.g., I'd rather avoid deriving from
FooStubin favor of structural subtyping. But then I don't know how to associateGeneratedFoowith attributes and methods as inFooStub.ilevkivskyi commentedon Nov 9, 2022
IIUC the situation, my personal preference would be to replace
...withraise AttributeNotGeneratedError. This way if empty stub is used accidentally, you will know immediately, instead of discovering randomNonesomewhere down the call stack.ilevkivskyi commentedon Nov 9, 2022
To clarify, mypy will also not complain about this.
Update --no-warn-no-return docs for empty body changes (#14065)
Update --no-warn-no-return docs for empty body changes (#14065)