-
Notifications
You must be signed in to change notification settings - Fork 288
-
In pandas, we have methods that can accept iterables of strings, but not a plain string. From useful_types, there is the SequenceNotStr type that is a sequence that doesn't include plain strings. But how can we do the same for iterables? I thought of doing something like this:
Example:
from typing import Iterable, overload, NoReturn @overload def func(s: str) -> NoReturn: ... @overload def func(s: Iterable[str]) -> list[str]: ... def func(s: Iterable[str]) -> list[str]: if isinstance(s, str): raise Exception("plain string not accepted") else: x = [v for v in s] return x # reveal_type(func("abc")) func("abc") v = 3 + 4 func({"a": 1, "b": 2})
This code will raise an exception as expected. If I uncomment the reveal_type() line, the type is revealed as NoReturn or Never by pyright and mypy, respectively. But pyright and mypy don't say that the line with v = 3 + 4 is unreachable.
Ideally, the type checker would show that func("abc") is an invalid call. How do we accomplish that?
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 2 comments 3 replies
-
Linking #256 for related discussion
Beta Was this translation helpful? Give feedback.
All reactions
-
But pyright and mypy don't say that the line with v = 3 + 4 is unreachable.
I think this may be a configuration issue. mypy-playground, pyright-playground
One caveat is that they only raise the unreachable on the next line, not on the line that produces the Never, which can lead to subtle false negatives. For example, if you have a return func("abc") in the last line of some function.
See: python/mypy#15821
Beta Was this translation helpful? Give feedback.
All reactions
-
I think this may be a configuration issue.
Yes, for pyright it is, and that's a new parameter as of a week ago. IMHO, the result of NoReturn in a case like this should be flagged differently. It should be "that's an invalid call". It's not about reachability - it's that you passed an incorrect parameter and the code will never return.
Take this simple example:
def foo() -> NoReturn: raise NotImplementedError foo()
Shouldn't the type checker say that foo() is problematic because it has a result of NoReturn. (Note: I realize this might be the topic of a different discussion).
Beta Was this translation helpful? Give feedback.
All reactions
-
A function signature with a NoReturn return type doesn't mean that the call is invalid. It means that it's valid but control will not return to the caller after the call. Refer to this section of the typing spec for details.
What you're looking for is a way to mark the overload as an error condition, which would require a new mechanism and an update to the existing overload call evaluation specification. There has been some discussion of this previously, but no one has driven a concrete proposal.
Beta Was this translation helpful? Give feedback.
All reactions
-
There has been some discussion of this previously, but no one has driven a concrete proposal.
I added an idea there - maybe it will get some traction.
Beta Was this translation helpful? Give feedback.