pycharm在处理继承自`functools.cached_property`的自定义装饰器时，其类型检查器可能无法正确推断类型，导致类型错误被忽略，而`mypy`则能正确识别。本文将探讨pycharm此行为的原因，并提供一种通过重命名自定义装饰器类来“欺骗”pycharm类型检查器的临时解决方案，以确保类型安全。
PyCharm 类型检查与自定义描述符的挑战
在python开发中，描述符（descriptor）是一种强大的机制，允许我们自定义属性的访问行为。functools.cached_property就是一个常见的描述符，它将一个方法转换为一个只计算一次的属性。然而，当开发者尝试创建自定义的、继承自cached_property的描述符时，可能会遇到PyCharm类型检查器行为异常的问题。
考虑以下代码示例，我们定义了一个名为result_property的自定义描述符，它继承自cached_property，并尝试在PyCharm中进行类型检查：
from functools import cached_property from collections.abc import Callable from typing import TypeVar, Generic, Any, overload, Union T = TypeVar("T") class result_property(cached_property, Generic[T]): def __init__(self, func: Callable[[Any], T]) -> None: super().__init__(func) def __set_name__(self, owner: type[Any], name: str) -> None: super().__set_name__(owner, name) @overload def __get__(self, instance: None, owner: Union[type[Any], None] = None) -> 'result_property[T]': ... @overload def __get__(self, instance: object, owner: Union[type[Any], None] = None) -> T: ... def __get__(self, instance, owner=None): return super().__get__(instance, owner) def func_str(s: str) -> None: print(s) class Foo: @result_property def prop_int(self) -> int: return 1 foo = Foo() func_str(foo.prop_int) # 期望此处出现类型错误
在这段代码中，foo.prop_int被定义为返回int类型。当将其作为参数传递给期望str类型的func_str函数时，理论上应该引发类型错误。mypy（一个流行的Python静态类型检查器）能够正确识别这个错误：
tmp.py:38: error: Argument 1 to "func_str" has incompatible type "int"; expected "str" [arg-type] Found 1 error in 1 file (checked 1 source file)
然而，PyCharm 2023.2.3（社区版）的类型检查器却报告此代码是正确的，未能识别出潜在的类型不匹配问题。这表明PyCharm在处理这种自定义描述符时，其类型推断机制可能存在局限性。
PyCharm 类型检查的内部机制分析
根据观察，PyCharm的静态类型检查器似乎对某些内置或常用名称（如cached_property）采用了硬编码的逻辑，而非完全依赖于通用的类型推断系统来解析装饰器或描述符的复杂类型行为。这意味着，它可能不是通过分析result_property的继承链和__get__方法的重载签名来推断类型，而是简单地查找特定的名称。
为了验证这一点，我们可以尝试一个简化的、甚至有些“虚假”的cached_property实现。如果PyCharm仅仅是根据名称进行判断，那么即使是一个不完整的实现，只要名称匹配，也可能触发其预期的类型检查行为：
def cached_property(func): # 注意：这里不是functools.cached_property def foo(self): pass # 这是一个不完整的实现，但名称是'cached_property' return foo def func_str(s: str) -> None: print(s) class Foo: @cached_property def prop_int(self) -> int: return 1 foo = Foo() func_str(foo.prop_int) # 此时PyCharm会报告：Expected type 'str', got 'int' instead
令人惊讶的是，即使是这样一个简化的、不完全符合cached_property行为的函数，只要其名称为cached_property，PyCharm就会正确地报告类型错误。这强烈支持了PyCharm的类型检查器在处理cached_property时，其逻辑是基于硬编码的名称而非严格的类型推断。
解决方案：重命名自定义描述符以匹配PyCharm的硬编码逻辑
既然PyCharm的类型检查器似乎对cached_property这个名称有特殊的处理逻辑，那么一个直接的解决方案就是将我们自定义的描述符类也命名为cached_property。这样，PyCharm就会应用其预设的类型检查规则，从而正确地识别类型错误。
以下是修改后的代码示例：
import functools from collections.abc import Callable from typing import TypeVar, Generic, Any, overload, Union T = TypeVar("T") # 将自定义描述符的类名改为 cached_property class cached_property(functools.cached_property, Generic[T]): def __init__(self, func: Callable[[Any], T]) -> None: super().__init__(func) def __set_name__(self, owner: type[Any], name: str) -> None: super().__set_name__(owner, name) @overload def __get__(self, instance: None, owner: Union[type[Any], None] = None) -> 'cached_property[T]': ... @overload def __get__(self, instance: object, owner: Union[type[Any], None] = None) -> T: ... def __get__(self, instance, owner=None): return super().__get__(instance, owner) def func_str(s: str) -> None: print(s) class Foo: @cached_property # 使用重命名后的装饰器 def prop_int(self) -> int: return 1 foo = Foo() func_str(foo.prop_int) # 此时PyCharm会报告：Expected type 'str', got 'int' instead
通过将result_property类重命名为cached_property，PyCharm现在能够正确地识别出foo.prop_int的实际类型是int，并在将其传递给期望str类型的func_str时报告类型错误。
注意事项与总结
- 临时性解决方案： 这种通过重命名类来解决问题的办法，本质上是一种利用PyCharm当前行为的“技巧”或“变通方案”。它并非理想的解决方案，因为它依赖于PyCharm可能在未来版本中改变的硬编码逻辑。
- 兼容性问题： 如果您的项目同时使用mypy等其他静态类型检查器，这种重命名可能不会影响mypy的行为，因为mypy通常会执行更严格和逻辑化的类型推断。
- PyCharm的改进期望： 理想情况下，PyCharm的类型检查器应该能够通过分析描述符的__get__方法签名和继承关系，进行更准确的类型推断，而不仅仅依赖于硬编码的名称。我们期待PyCharm在未来的版本中能够改进其对自定义描述符的类型检查能力。
- 确保类型安全： 尽管这是一个权宜之计，但在PyCharm尚未提供更完善的描述符类型推断之前，使用此方法可以帮助开发者在ide中获得更准确的类型错误提示，从而提高代码的健壮性和可维护性。
总而言之，当PyCharm在处理继承自functools.cached_property的自定义描述符时出现类型检查不准确的情况，一个有效的临时解决方案是将其类名更改为cached_property，以利用PyCharm内部对该名称的特殊处理逻辑。