Frozen dataclasses: sealable
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
Research direction
No files, tests, or entry points are named in the issue. Start by locating the project's dataclass-related implementation and test conventions, then assess how the requested Python 3.9 behavior and sealable-field semantics can be specified and verified.
Written by the indexing model from the issue text.
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.
- Dominant language
- Python
- Stars
- 1.2k
- Forks
- 127
- Avg merge
- 2h 13m
- Merged PRs (30d)
- 1
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from tmux-python/libtmux
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
tmux-python/libtmux#759 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
tmux-python/libtmux#745 · 2 comments ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
tmux-python/libtmux#744 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
tmux-python/libtmux#731 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
tmux-python/libtmux#654 ·
All issues in tmux-python/libtmux
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
use-agent-os/agent-os#3314 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
BasedHardware/omi#15662 · 1 comment ·
-
documentation help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
AiursoftWeb/AnduinOS-2#19 ·