在 Python 3.8 以下的版本（主要指 Python 3.5 至 3.7）中，无法直接使用 `typing.Protocol`（它是在 Python 3.8 中作为标准库的一部分正式引入的）来创建基于结构子类型的类型注解。然而，我们依然有几种有效的方法来定义和要求一个实例必须提供特定的属性和方法，主要通过**抽象基类 (ABC)** 和 **类型提示 (Type Hints)** 的组合来实现，并辅以**自定义描述符**或**运行时检查**来增强约束力。 ### 1. 核心方案：抽象基类 (ABC) 与类型提示 这是最直接、最标准的方法。通过 `abc.ABC` 和 `@abstractmethod` 装饰器定义一个抽象基类，明确声明所需的抽象方法和属性。然后，在函数或变量的类型注解中使用这个抽象类作为类型。类型检查器（如 mypy）会强制要求传入的参数是该抽象类的具体子类实例。 #### 代码示例：定义抽象基类并用于类型注解 ```python from abc import ABC, abstractmethod from typing import List # 1. 定义一个抽象基类，要求子类必须实现特定方法和属性 class DataSource(ABC): """抽象数据源，要求子类必须提供 `data` 属性和 `fetch` 方法。""" # 使用 @property 和 @abstractmethod 定义抽象属性 @property @abstractmethod def data(self) -> List[str]: """一个只读属性，返回字符串列表。""" pass # 定义抽象方法 @abstractmethod def fetch(self, query: str) -> bool: """根据查询获取数据，返回成功与否。""" pass # 抽象类中可以包含具体实现的方法（可选） def get_summary(self) -> str: return f"Data source with {len(self.data)} items." # 2. 创建具体子类，必须实现所有抽象成员 class FileDataSource(DataSource): def __init__(self, filepath: str): self._filepath = filepath self._cached_data = [] @property def data(self) -> List[str]: # 实现抽象属性 if not self._cached_data: # 模拟从文件读取 self._cached_data = ["line1", "line2", "line3"] return self._cached_data def fetch(self, query: str) -> bool: # 实现抽象方法 print(f"Fetching from file {self._filepath} with query: {query}") # 模拟获取逻辑 return True class APIDataSource(DataSource): def __init__(self, endpoint: str): self.endpoint = endpoint self._data = ["api_item1", "api_item2"] @property def data(self) -> List[str]: return self._data def fetch(self, query: str) -> bool: print(f"Fetching from API {self.endpoint} with query: {query}") return False # 3. 在函数中使用抽象基类进行类型注解 def process_source(source: DataSource) -> None: """ 参数 source 被注解为 DataSource 类型。 静态类型检查器（如 mypy）会确保传入的实参是 DataSource 的子类实例。 """ if source.fetch("some_query"): print(f"Processing data: {source.data}") print(source.get_summary()) # 可以调用基类的具体方法 else: print("Fetch failed.") # 4. 使用符合要求的实例 file_source = FileDataSource("/path/to/data.txt") api_source = APIDataSource("https://api.example.com/data") process_source(file_source) # 类型检查通过，运行正常 process_source(api_source) # 类型检查通过，运行正常 # 5. 不符合要求的类将无法通过类型检查或运行时实例化 class IncompleteSource(DataSource): """缺少 `data` 属性的实现，此类仍是抽象的。""" def fetch(self, query: str) -> bool: return True # 以下代码在静态类型检查时会报错，运行时也会引发 TypeError # source = IncompleteSource() # TypeError: Can't instantiate abstract class IncompleteSource... # process_source(source) # mypy: Argument 1 to "process_source" has incompatible type "IncompleteSource"; expected "DataSource" ``` **方案优势与限制**： * **优势**：标准、明确，通过继承建立了强契约。类型检查器支持良好，IDE 智能提示准确。 * **限制**：要求所有符合该类型的类都必须**显式继承**自这个抽象基类。对于无法修改源码的第三方库中的类，此方法无效[ref_1][ref_3]。 ### 2. 备选方案：使用 `typing` 中的通用类型与回调协议（Python 3.5+） 在 Python 3.5+ 的 `typing` 模块中，虽然没有 `Protocol`，但我们可以利用 `Callable`、`TypeVar` 和 `Union` 等工具，结合函数签名来近似描述“拥有特定方法的对象”。但这通常只适用于方法，对属性的描述能力较弱。 #### 代码示例：使用 `Callable` 和 `TypeVar` 描述方法要求 ```python from typing import TypeVar, Callable, List, Any # 定义一个类型变量，代表任意类型 T = TypeVar('T') # 描述一个“拥有 `connect` 方法的对象”，该方法接受一个字符串参数并返回布尔值。 # 这实际上是在描述一个“可调用对象”的签名，而非一个类。 Connectable = Callable[[str], bool] def use_connector(connector: Connectable, target: str) -> None: """期望 connector 是一个可调用对象，其签名如 `def __call__(self, target: str) -> bool`""" success = connector(target) print(f"Connection {'succeeded' if success else 'failed'}.") # 一个符合 Connectable 签名的类（通过实现 __call__ 方法） class SimpleConnector: def __call__(self, target: str) -> bool: print(f"Connecting to {target}...") return True # 使用 connector_obj = SimpleConnector() use_connector(connector_obj, "database") # 类型检查通过 # 一个普通函数也符合 Connectable 类型 def connect_func(host: str) -> bool: return False use_connector(connect_func, "server") # 类型检查通过 ``` **此方案的局限性**： 1. 它描述的是**可调用对象**的签名，而不是一个拥有该方法的**对象**。对于 `obj.method()` 形式的调用，此方法无能为力。 2. 无法描述对**属性**的要求。 3. 描述多个方法时，需要定义复杂的联合类型或回调类型，可读性和实用性较差。 ### 3. 增强方案：运行时检查与描述符 为了弥补纯类型注解在运行时不强制检查的不足（Python 的类型注解本身是“渐进式”的，不强制运行时类型[ref_3]），我们可以在抽象基类的基础上，结合 `__init_subclass__` 或自定义描述符，在**类创建时**或**实例化时**进行运行时验证。 #### 代码示例：使用 `__init_subclass__` 进行类级别的运行时检查 ```python from abc import ABC, abstractmethod from typing import get_type_hints class EnforcedDataSource(ABC): """一个在子类创建时检查是否实现了特定类型注解的抽象基类。""" @property @abstractmethod def data(self) -> list: # 这里使用更通用的类型，检查逻辑更关注“存在性” pass @abstractmethod def fetch(self, query: str) -> bool: pass def __init_subclass__(cls, **kwargs): """当子类被创建时，自动调用此方法。""" super().__init_subclass__(**kwargs) # 检查是否实现了抽象属性 `data` if 'data' not in cls.__dict__ or not isinstance(cls.__dict__['data'], property): # 更严格的检查可以检查 getter 方法是否存在 raise TypeError(f"Can't instantiate abstract class {cls.__name__} without implementing the abstract property 'data'") # 检查是否实现了抽象方法 `fetch` if 'fetch' in cls.__abstractmethods__: raise TypeError(f"Can't instantiate abstract class {cls.__name__} without implementing the abstract method 'fetch'") print(f"Class {cls.__name__} passed runtime interface check.") # 正确的子类 class GoodSource(EnforcedDataSource): @property def data(self): return [] def fetch(self, query): return True # 尝试创建不完整的子类会在定义时立即报错 try: class BadSource(EnforcedDataSource): @property def data(self): return [] # 缺少 fetch 方法 except TypeError as e: print(f"定义类时捕获错误: {e}") # 输出: Can't instantiate abstract class BadSource... ``` ### 4. 总结与最佳实践建议 对于 Python 3.8 以下版本，创建要求实例提供特定属性和方法的类型注解，**首选方案是抽象基类 (ABC)**。 | 需求场景 | 推荐方案 | 关键代码/说明 | | :--- | :--- | :--- | | **设计时约束，构建类体系** | **抽象基类 (ABC)** | `from abc import ABC, abstractmethod` <br> 使用 `@abstractmethod` 和 `@property` + `@abstractmethod` 定义接口。 | | **为函数参数提供清晰类型提示** | **使用抽象基类作为类型注解** | `def func(obj: MyABC): ...` <br> 结合 mypy 等工具进行静态检查[ref_2]。 | | **确保第三方库的类在运行时符合接口** | **鸭子类型 + 文档约定** | 无法使用类型注解强制。应在函数内部使用 `hasattr(obj, 'attr')` 和 `callable(getattr(obj, 'method', None))` 进行防御性检查，并在文档中明确说明要求。 | | **在类定义时进行额外的接口验证** | **在抽象基类中使用 `__init_subclass__`** | 如上面示例所示，可以在子类创建时增加自定义的验证逻辑。 | **最终建议工作流**： 1. **定义接口**：使用 `abc.ABC` 和 `@abstractmethod` 创建一个抽象基类，在其中声明所有必需的属性和方法[ref_1]。 2. **实现具体类**：创建继承自该抽象基类的具体子类，并实现所有抽象成员。 3. **进行类型注解**：在函数签名、变量声明等处，使用该抽象基类作为类型提示[ref_3]。 4. **配置静态类型检查**：在项目中配置 mypy（在 `mypy.ini` 中设置 `python_version = 3.7` 等），使其在 CI/CD 流程或本地开发时强制执行类型检查，确保所有使用该类型注解的地方传入的都是正确的子类实例[ref_2]。 5. **（可选）增加运行时保障**：如果对安全性要求极高，可以在抽象基类中添加 `__init_subclass__` 逻辑或使用描述符，在程序启动或实例化时进行二次验证。 通过以上组合策略，即使在 Python 3.8 之前，也能有效地利用类型系统来表达和约束“实例必须提供特定属性和方法”这一需求，并兼顾开发体验和代码质量。