-
Notifications
You must be signed in to change notification settings - Fork 258
Typing Documentation: NoReturn intent is ambiguous #695
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
Comments
The first interpretation is the correct one. A bare or no return is equivalent to returning |
Thanks so much for your clarity on that. Do you think this warrants a tweak to the documentation to make that more obvious? |
Regarding the behavior of your specific examples:
If it helps, mypy internally represents This is strictly speaking an implementation detail though: all PEP 484 says is that NoReturn is used to "annotation functions that never return normally [...] for example by unconditionally raising an exception". Though personally, I find this restriction to be mildly unfortunate/inconvenient. python/mypy#5818 has some related discussion. Also, just to give some context, I think the official typing docs historically have usually been updated only as an afterthought to the core typing design/implementation work. So I'm sure there's lots of low-hanging fruit there. |
This makes sense, and is essentially what we had concluded on before I wrote up this bug report. None the less, in some languages there doesn't appear to be a clear distinction between the concepts of none and never so this may cause confusion among people who typing is new to and they come from a background where no distinction is made. C's void type is what I have in mind - but perhaps I've misunderstood the void type all along. |
This is incredibly helpful, thanks for the explanation! This was the primary driver behind the confusion as I expected it to fail. I had a few notes that were pointing to the wrong functions due to changes in the numbers, so I have edited my post to fix some of those (more might exist). I should have bothered figuring out nice names for them rather than arbitrary numbers. To be clear, the only one that actually fails is function7, but function8 depends on function7 so they both have to be commented to pass tests |
After lots of internal discussion, it seems that myself with some colleagues at work have concluded that the intent of
NoReturn
(official docs, pep484) is ambiguous, at least as listed in the docs.There are 2 schools of thought. The first is that
NoReturn
is only used when the function called never passes back control to the parent in the stack. This would mean all code below calling a function with NoReturn would be unreachable.The second school of thought is that
NoReturn
is used for functions which perform processing but do not explicitly return a value. This would mean that code below calling a function with NoReturn may be reachable, but you should not ever assign the value of a function with NoReturn to a variable (this would be true in both schools of thought).The closer we thought we were to an explanation, we found information that brought doubt back in. For now we have settled on Assumption1, but the docs could easily clear this up.
Here is some demo code to explain the point
Edited: Updated example code in efforts to be more clear
The text was updated successfully, but these errors were encountered: