Bounded generic type parameter not narrowed past its upper bound, regardless of argument value
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 38/100
Hướng nghiên cứu
Bắt đầu bằng cách tái hiện ví dụ từ issue với các thiết lập mypy.ini được hiển thị và kiểm tra hành vi suy luận generic đối với _E TypeVar bị giới hạn. Ví dụ triển khai liên quan là poltergeist/decorator.py; được xem là hoàn tất khi kết quả của reveal_type giữ nguyên TypeError | ValueError thay vì mở rộng _E thành BaseException.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Bug Report
If a generic type variable _E has an upper bound B, the upper bound B seems to be used as the inferred type of _E when inferring other type variables that depend on _E, even if there is a more specific type that _E could be narrowed to.
This becomes an issue when trying to infer error types returned by poltergeist (a simple library that provides a generic Result = Ok[_T] | Err[_E] utility type).
To Reproduce
from poltergeist import catch
@catch(TypeError, ValueError)
def validate_positive_number(int_or_str: int | str) -> int:
if isinstance(int_or_str, str):
raise TypeError("Input must be an integer")
if int_or_str <= 0:
raise ValueError("Input must be positive")
return int_or_str
def do_something_with_positive_number(int_or_str: int | str) -> None:
validated_number_result = validate_positive_number(int_or_str)
reveal_type(validated_number_result) # Revealed type is "Union[poltergeist.result.Ok[builtins.int], poltergeist.result.Err[builtins.Exception]]" Mypy
The implementation of catch can be found here:
Source code for the `catch` decorator
import functools
from collections.abc import Awaitable
from typing import Callable, ParamSpec, TypeVar, reveal_type
from poltergeist.result import Err, Ok, Result
_T = TypeVar("_T")
_E = TypeVar("_E", bound=BaseException)
_P = ParamSpec("_P")
def catch(
*errors: type[_E],
) -> Callable[[Callable[_P, _T]], Callable[_P, Result[_T, _E]]]:
def decorator(func: Callable[_P, _T]) -> Callable[_P, Result[_T, _E]]:
@functools.wraps(func)
def wrapper(*args: _P.args, **kwargs: _P.kwargs) -> Result[_T, _E]:
try:
result = func(*args, **kwargs)
except errors as e:
return Err(e)
return Ok(result)
return wrapper
return decorator
def catch_async(
*errors: type[_E],
) -> Callable[[Callable[_P, Awaitable[_T]]], Callable[_P, Awaitable[Result[_T, _E]]]]:
def decorator(
func: Callable[_P, Awaitable[_T]]
) -> Callable[_P, Awaitable[Result[_T, _E]]]:
@functools.wraps(func)
async def wrapper(*args: _P.args, **kwargs: _P.kwargs) -> Result[_T, _E]:
try:
result = await func(*args, **kwargs)
except errors as e:
return Err(e)
return Ok(result)
return wrapper
return decorator
Expected Behavior
mypy should be able to accurately use the value of errors to narrow the inferred type of _E within catch, and thus infer that validated_number_result is of type Result[int, TypeError | ValueError].
Actual Behavior
Mypy keeps _E inferred to its upper bound BaseException, thus inferring validated_number_result as Result[int, BaseException].
By contrast, pylance's type checker is able to narrow validated_number_result as expected:
Your Environment
- Mypy version used: 1.15.0
- Mypy configuration options from
mypy.ini(and other config files):
mypy.ini
[mypy]
python_version = 3.13
mypy_path = typings
ignore_missing_imports = True
check_untyped_defs = True
disallow_untyped_defs = True
disallow_untyped_calls = True
strict_equality = True
disallow_any_unimported = True
warn_return_any = True
no_implicit_optional = True
pretty = True
show_error_context = True
show_error_codes = True
show_error_code_links = True
no_namespace_packages = True
- Python version used: 3.13.0
Unsure if related to #19081 , but it's possible, given that both these issues are related to retaining information via generic type parameters.
- Ngôn ngữ chính
- Python
- Star
- 20.6k
- Fork
- 3.3k
- Merge trung bình
- 1 ngày 18 giờ
- Pull request đã merge (30 ngày)
- 54
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của python/mypy
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
-
documentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
bug topic-configuration topic-error-reporting
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Issue tương tự
-
link-check link-check:sphinx-theme
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
qgis/QGIS-Documentation#11275 ·
-
bug priority:normal ready-for-dev
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
OpenHands/extensions#626 · 1 bình luận ·
-
Change observation tooltip text Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
CSCfi/sd-search-api#39 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100