Fix crash on dataclass field assigned a functional namedtuple() call - #21849
Open
TheMuffinMan1320 wants to merge 1 commit into
Open
Fix crash on dataclass field assigned a functional namedtuple() call#21849TheMuffinMan1320 wants to merge 1 commit into
TheMuffinMan1320 wants to merge 1 commit into
Conversation
…ython#21583) When a dataclass field's default value is a `namedtuple('Name', ...)` call, the semantic analyzer treats the assignment as a NamedTuple class definition and binds the field's name to a TypeInfo instead of a Var, regardless of any type annotation on the left-hand side. The dataclass plugin's collect_attributes() assumed every non-alias, non-decorator symbol table node was a Var and asserted so, crashing when it encountered this TypeInfo. Skip such fields the same way TypeAlias/Decorator nodes are already skipped, since they aren't valid dataclass fields. Fixes python#21583
Contributor
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #21583
Root cause
crashes mypy with:
When the right-hand side of a class-body assignment is a
namedtuple(...)call, mypy's semantic analyzer (
analyze_namedtuple_assigninmypy/semanal.py) always treats the statement as a functional NamedTupleclass definition and binds the assigned name in the class's symbol table to
a
TypeInfo, regardless of whether the left-hand side also carries a typeannotation. So
p's symbol table entry ends up being aTypeInfofor asynthesized
Pointclass, not aVar, even though it looks like a normalannotated dataclass field.
DataclassTransformer.collect_attributes()inmypy/plugins/dataclasses.pydid not anticipate this and unconditionally asserted
isinstance(node, Var)for any class-body annotated assignment that wasn'talready special-cased (
TypeAlias,Decorator), causing the crash.Fix
Skip such fields the same way
TypeAliasandDecoratornodes are alreadyskipped in
collect_attributes(), since a name bound to aTypeInfothisway is not a valid dataclass field. This mirrors the existing handling
immediately above it in the same function and does not touch the
Var-based path used by ordinary dataclass/NamedTuple fields.Testing
testNoCrashForDataclassFieldAssignedFunctionalNamedTupletotest-data/unit/check-dataclasses.test, covering both thename-mismatched case from the issue and a name-matched variant.
python -m pytest -q mypy/test/testcheck.py -k dataclass— 204 passed.python -m pytest -q mypy/test/testcheck.py -k "namedtuple or NamedTuple"— 225 passed.that normal dataclass fields with forward-referenced
NamedTupleclass types still type-check correctly.
pre-commit run --files mypy/plugins/dataclasses.py test-data/unit/check-dataclasses.test— all checks passed.