Repository navigation
--strict-optional Doesn't consider cases missing return #2366
Description
def foo(a: bool) -> str:
if a:
return 'Hello world'Type checks cleanly with --strict-optional but will return None in cases where a is False. This function should have to have a type signature of (bool) -> Optional[str].
I recently came across the --warn-no-return flag in #1748 . Is the intention is to force all code paths in functions to hit a return statement? I know that'd be more in line with PEP 8, but unfortunately I've got tons of code that relies on the absence of a return statement implying return None that I'd like to typecheck.
If this isn't a bug, I would suggest we change this to "--strict-optional should imply --warn-no-return".
Activity
rwbarton commentedon Oct 28, 2016
Relies on what behavior?
rowillia commentedon Oct 28, 2016
@rwbarton updated my issue...code that relies on no return statement returning
Nonegvanrossum commentedon Oct 28, 2016
In the meantime you can just pass both flags right?
rwbarton commentedon Oct 28, 2016
OK. The way
--warn-no-returnworks is effectively that it inserts areturn Noneat the end of your function if it is possible for execution to flow off the end of the function. IfNoneis a legal return value for your function, for example if your function is declared to returnNone, orOptional[int], etc., then this is no problem, but for a function like yourfoo, it'll be an error becauseNonedoes not have typestr(under--strict-optional).--strict-optionalimplying--warn-no-returnis probably not a good default right now because--warn-no-returnis brand new, but perhaps it could be in the future. It's easy enough to just pass both flags of course, but the downside of the status quo is that people have to discover the--warn-no-returnoption, and the lack of this check is reported pretty often as a bug, so it would probably be worth turning it on by default once the kinks have been worked out.gvanrossum commentedon Oct 28, 2016
Always, or implied by
--strict-optional? (Assuming the latter will take much longer to have its kinks worked out.)rowillia commentedon Oct 28, 2016
@gvanrossum Totally, but it would be a nice user experience to have them work in tandem since your types aren't really strict about optionals unless we've also asserted that all code paths return values. I agree with @rwbarton that we should iron out the kinks first though 😄
As a side note, it seems like
--warn-no-returnis fairly noisy - Filed #2370rwbarton commentedon Oct 28, 2016
Oops, I forgot how
--warn-no-returnworks. What it actually does is reject implicitly returningNoneby falling off the end of the function unless the function is declared as returning exactlyNone. This means it's actually useful without strict optional checking, but it also means yourfoowon't work even if the return type is changed toOptional[str].It'd be easy to make it more lenient under strict optional checking; when it was implemented strict optional checking didn't really work well yet (and even mypy itself is not yet using it).
ddfisher commentedon Oct 28, 2016
I don't think we should make it more lenient, though -- falling off the end of the function in those cases is still potentially an error, and it seems reasonable it me to make people be explicit. (Just like we don't allow you to write
returnin a function that returnsOptional[int].)I'd like to see
--warn-no-returnbecome the global default. In my experience so far, it's caught a bunch of errors with a very low false positive rate.ilevkivskyi commentedon Nov 7, 2019
Both
--strict-optionaland--warn-no-returnare on by default, so I don't think this is relevant anymore (and also not giving an error with--no-warn-no-returnseems right to me).