-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Try block handling assumes all statements could have succeeded #13123
Comments
Just a friendly suggestion, but it's probably clearer to use a different variable name when the type is different. Consider renaming the return value to |
Of course, that's basically what I did in the actual code, but MyPy should still be able to handle this properly in general. My issue specifically is that the type narrowing is lost in the except block when it's impossible for it to have changed types. Here's a much simpler example focused on this: # type_test_str_int.py
from __future__ import annotations
def ensure_int(num: str | int) -> int:
if isinstance(num, str):
try:
reveal_type(num) # str
num = int(num)
except ValueError:
reveal_type(num) # str | int ??
num = int(num.replace('pfx', ''))
return num
As you said, using a new variable avoids this problem, but that doesn't mean it couldn't be handled better. Here's an interesting follow up example that uses a new variable: # type_test_str_int2.py
from __future__ import annotations
def ensure_int(num: str | int) -> int:
if isinstance(num, str):
try:
actual_num = int(num)
except ValueError:
reveal_type(actual_num)
actual_num = int(num.replace('pfx', ''))
return actual_num
This code should really be throwing multiple errors at me, but MyPy isn't really focused on undefined variables, which is fine. However, it probably shouldn't be defined inside the except block since that line couldn't have succeeded. When dealing with the except block(s), ignoring the type changes from the last/only line of the body should avoid this and properly report that it is undefined, as well as solving the original issue so a second variable isn't required. I've also noticed a similar issue with closure functions, especially decorators with optional arguments that follow this pattern: # type_test_deco.py
from __future__ import annotations
from functools import partial
from typing import Callable, Any, TypeVar, overload
F = TypeVar('F', bound=Callable[..., Any])
@overload
def decorator(func: F, *args: Any, **kwargs) -> F: ...
@overload
def decorator(func: None = None, *args: Any, **kwargs) -> Callable[[F], F]: ...
def decorator(
func: F | None = None,
*args: Any,
**kwargs: Any,
) -> F | Callable[[F], F]:
if func is None:
return partial(decorator, *args, **kwargs)
reveal_type(func) # `F`
# Use args and kwargs here
def _wrapper(*a: Any, **kw: Any) -> Any:
reveal_type(func) # `F | None` ??
return func(*a, **kw)
return _wrapper
In this example, an explicit typed assignment/cast would solve the problem, but that really shouldn't be necessary due to type narrowing. It's impossible for |
Bug Report
When a try block is used to attempt to convert/consolidate the type of a variable, the except block assumes the conversion may or may not have happened. For try blocks with multiple statements, this is the correct behavior for every line but the final one as mypy can't know which of those lines succeeded. However, I would expect mypy to understand that the last/only line can't have executed.
To Reproduce
Minimal example similar to where I encountered the issue:
Expected Behavior
mypy shouldn't have any errors:
Actual Behavior
mypy finds an error in the except block:
Your Environment
mypy 0.961 (compiled: yes)
mypy.ini
(and other config files): N/AThe text was updated successfully, but these errors were encountered: