Description
Task:
Provide a structured summary and action plan for implementing a Python 3.9-compatible function, frozen_dataclass_sealable(). This function should emulate frozen dataclasses but uniquely allow inheritance between frozen and non-frozen dataclasses. Ensure the proposed implementation explicitly addresses the provided test requirements.
Constraints and Clarifications:
- Clearly indicate complexity or feasibility concerns (rated on a scale from 1 to 10) if certain test requirements—such as implementing
__slots__—are too complex or impractical to satisfy. - Simplicity and practicality are prioritized. It is acceptable to impose limitations, such as not achieving complete immutability (true freezing), particularly regarding mutable attributes like lists.
Non-negotiable Requirements:
| # | Requirement | Clarification |
|---|---|---|
| 1 | Field inheritance between frozen and non-frozen dataclasses must be supported | Derived classes should inherit and extend fields without restriction from frozen parents |
| 2 | Full compatibility with type annotations and static type analysis (auto-completion, IDE support) | Type hints and static checks (e.g., mypy) must remain fully accurate and reliable |
| 3 | Python 3.9+ compatibility required | No backward compatibility below Python 3.9 necessary |
Concept Explanation: "Sealable Fields":
A "sealable field" is temporarily mutable during initialization, specifically within the context of __post_init__(). After initialization (seal()), these fields become effectively immutable. Static type checkers and IDE tools should treat these fields as read-only outside the initialization phase.
The rationale is to allow complex object graphs and circular or bi-directional dependencies to be resolved naturally during __post_init__() initialization.