本文深入探讨了在使用`functools.cached_property`及其自定义子类时，mypy类型检查行为不一致的问题。当直接使用`cached_property`时，mypy能正确推断类型并报告错误；但当继承`cached_property`而不添加额外类型提示时，mypy可能无法正确推断类型。文章提供了详细的解决方案，通过引入`typing.generic`和`typevar`，确保自定义的属性装饰器能正确传递类型信息，从而恢复mypy的精确类型检查能力。
理解Mypy对cached_property及其子类的类型推断差异
在Python中，functools.cached_property是一个非常有用的装饰器，它将方法转换为一个只计算一次结果的属性。Mypy作为静态类型检查工具，通常能够很好地处理这类标准库装饰器，并进行准确的类型推断。然而，当开发者尝试通过继承cached_property来创建自定义属性装饰器时，Mypy的行为可能会出乎意料。
考虑以下使用cached_property的示例代码：
from functools import cached_property
def func(s: str) -> None:
print(s)
class Foo:
@cached_property
def prop(self) -> int:
return 1
foo = Foo()
func(foo.prop)当Mypy对这段代码进行检查时，它会识别出foo.prop的类型是int，而func函数期望接收一个str类型参数，因此会报告一个类型不兼容的错误：error: Argument 1 to "func" has incompatible type "int"; expected "str"。这正是我们期望的Mypy行为，它正确地捕获了类型不匹配的问题。
然而，当我们创建一个cached_property的简单子类，例如result_property，并用它来装饰相同的方法时，Mypy的行为却发生了变化：
from functools import cached_property
def func(s: str) -> None:
print(s)
class result_property(cached_property):
pass
class Foo:
@result_property
def prop(self) -> int:
return 1
foo = Foo()
func(foo.prop)令人惊讶的是，对这段代码运行Mypy检查，结果却是Success: no issues found in 1 source file。尽管result_property没有任何额外的逻辑，仅仅是cached_property的直接继承，Mypy却未能像之前那样报告类型错误。这表明Mypy在处理标准库装饰器和其自定义子类时，类型推断的深度和机制有所不同。
Mypy类型推断差异的根源
Mypy在处理内置或标准库中定义的装饰器（如cached_property）时，可能内置了特殊的逻辑或类型存根（type stub），使其能够准确地理解这些装饰器的行为并推断出被装饰方法的返回类型。然而，当遇到一个自定义的、简单的cached_property子类时，Mypy可能不会自动应用同样深度的类型推断。它可能仅仅将其视为一个普通的描述符，而未能正确地“看穿”其内部，从而无法将装饰方法的返回类型（例如int）正确地关联到属性的访问结果上。
这意味着，为了让Mypy能够正确地推断出继承自cached_property的自定义装饰器的类型，我们需要提供更明确的类型提示，以帮助Mypy理解这个自定义类是如何影响被装饰方法的类型的。
解决方案：使用泛型和类型变量
要解决这个问题，我们需要在自定义的result_property类中明确地使用Python的类型系统，特别是typing.Generic和typing.TypeVar，来模拟cached_property的类型行为。这样可以确保类型信息从被装饰的方法正确地传递到属性的访问结果。
以下是修正后的result_property实现：
from functools import cached_property
from typing import Generic, TypeVar, Callable, Any
# 定义一个类型变量T，用于表示被装饰方法的返回类型
T = TypeVar('T')
# result_property继承自Generic[T]和cached_property
class result_property(Generic[T], cached_property):
# __init__方法需要明确接收一个Callable[..., T]类型的函数
def __init__(self, func: Callable[..., T]) -> None:
super().__init__(func)
def func(s: str) -> None:
print(s)
class Foo:
@result_property
def prop(self) -> int:
return 1
foo = Foo()
func(foo.prop) # 此时Mypy应再次报告错误代码解析：
- T = TypeVar('T'): 定义了一个类型变量T。这个T将用于表示被result_property装饰的方法的返回类型。
-
class result_property(Generic[T], cached_property)::
- Generic[T]：这使得result_property成为一个泛型类。当Mypy看到@result_property装饰一个返回类型为int的方法时，它会推断出这个result_property实例的T类型参数是int。
- cached_property：保持继承关系。
-
def __init__(self, func: Callable[..., T]) -> None::
- 关键在于func: Callable[..., T]。这里明确告诉Mypy，result_property的构造函数期望接收一个可调用对象func，这个func的返回类型是T（也就是我们定义的类型变量）。
- 通过super().__init__(func)，我们调用了父类cached_property的初始化方法，确保其内部机制正常工作。
通过上述修改，Mypy现在能够正确地理解@result_property装饰器的工作方式。当它看到@result_property装饰了prop方法，而prop方法的返回类型是int时，它会推断出result_property实例的泛型参数T为int。因此，当访问foo.prop时，Mypy就能正确地识别其类型为int，从而再次报告func(foo.prop)处的类型不兼容错误。
总结与注意事项
- 明确类型提示的重要性： 当你继承或扩展Python标准库中的复杂类型（如描述符或装饰器）时，仅仅继承可能不足以让Mypy进行准确的类型推断。你需要通过typing模块提供的工具（如Generic、TypeVar、Callable等）来明确地声明类型行为。
- 模拟父类接口： 在自定义装饰器或描述符时，确保其__init__方法签名及其泛型定义能够准确地反映其父类的类型接口，这样Mypy才能更好地理解其行为。
- Mypy的内部机制： Mypy对标准库的特殊处理是其提高可用性的方式，但这也意味着在自定义类似功能时，需要更积极地提供类型信息来弥补这种“特殊处理”的缺失。
通过上述方法，我们可以确保自定义的属性装饰器在Mypy的严格类型检查下依然表现良好，从而提高代码的健壮性和可维护性。
