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
I haven't received any answers to the following StackOverflow post, so I thought I'd also post it here. I'm not sure if it's an actual bug or if it's just considered good practice to always have something like else: raise Exception at the end of if / elif block.
I am getting a MyPy error "Missing return statement", even when I check for all possible cases inside a function.
For example, in the following code, MyPy is still giving me an error "9: error: Missing return statement", even though color can only be Color.RED, Color.GREEN, or Color.BLUE, and I test all those cases!
This code is fragile; if Color will change, it will silently break. The right way IMO is to add assert False at the end. This will also silence mypy.
To the point, I don't think it's worth the special casing inside mypy. If we'll ever have singleton types, it might be possible to make it work out of the box.
PEP 484 actually explicitly specifies that examples like this should be supported. I am not sure if we already have an issue for this, so I will keep this open.
Uh oh!
There was an error while loading. Please reload this page.
I haven't received any answers to the following StackOverflow post, so I thought I'd also post it here. I'm not sure if it's an actual bug or if it's just considered good practice to always have something like
else: raise Exception
at the end ofif / elif
block.I am getting a MyPy error "Missing return statement", even when I check for all possible cases inside a function.
For example, in the following code, MyPy is still giving me an error
"9: error: Missing return statement"
, even thoughcolor
can only beColor.RED
,Color.GREEN
, orColor.BLUE
, and I test all those cases!The text was updated successfully, but these errors were encountered: