Dataclass transform should ignore TypeAlias variables #91322
Description
| BPO | 47166 |
|---|---|
| Nosy | @ericvsmith, @JelleZijlstra, @AlexWaygood, @GBeauregard, @thomkeh |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2022-03-30.14:49:32.604>
labels = ['type-bug', '3.8', '3.9', '3.10', '3.11', '3.7', 'library']
title = 'Dataclass transform should ignore TypeAlias variables'
updated_at = <Date 2022-04-06.22:47:22.436>
user = 'https://github.com/thomkeh'bugs.python.org fields:
activity = <Date 2022-04-06.22:47:22.436>
actor = 'thomkeh'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2022-03-30.14:49:32.604>
creator = 'thomkeh'
dependencies = []
files = []
hgrepos = []
issue_num = 47166
keywords = []
message_count = 5.0
messages = ['416368', '416414', '416426', '416428', '416903']
nosy_count = 5.0
nosy_names = ['eric.smith', 'JelleZijlstra', 'AlexWaygood', 'GBeauregard', 'thomkeh']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue47166'
versions = ['Python 3.7', 'Python 3.8', 'Python 3.9', 'Python 3.10', 'Python 3.11']Metadata
Metadata
Assignees
Labels
Projects
Milestone
Relationships
Development
No branches or pull requests
Participants
Activity
thomkeh commentedon Mar 30, 2022
The dataclass transformation ignores attributes that are annotated as ClassVar. I think it should also ignore attributes that are annotated as TypeAlias.
Specifically, I have this usecase in mind:
JelleZijlstra commentedon Mar 31, 2022
From a typing perspective this is reasonable. See this thread about type aliases in class scopes: https://mail.python.org/archives/list/typing-sig@python.org/thread/CGOO7GPPECGMLFDUDXSSXTRADI4BXYCS/
However, it's a niche use case and we could decide that we don't want to further complicate the annotation parsing in dataclasses.py.
AlexWaygood commentedon Mar 31, 2022
I think implementing this would add complexity to the code in dataclasses.py (though Eric's the expert!).
For your use case, is it essential that the type alias declaration be inside the class scope? Would it be possible for you to simply have the alias declaration in the global scope instead?
ericvsmith commentedon Mar 31, 2022
Same question as Alex: what does the TypeAlias being inside the class offer that being at module level doesn't?
thomkeh commentedon Apr 6, 2022
There is of course no hard reason for not using the global scope. I just often have enums (or other types) that are very closely linked to one class. And it makes sense to me then to have a TypeAlias in that class so that I don't have to import the enum separately.
For normal classes, the nested TypeAlias works completely fine in the type checkers I tested (pyright and mypy). It's just dataclasses that are the problem.
But I see now that there is a general wish to keep the implementation of dataclass simple, which I can understand.