Fix bugs where overriding init in a dataclass subclass crashed mypy #8159
Conversation
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
This fixes two bugs related to dataclass InitVars and overriding __init__ (python#8022 and python#8015) by changing mypy to ignore InitVars in parent classes when the class supplied its own __init__ and set (init=False) on the dataclass. It also fixes a bug with multiple inheritance of dataclasses. Previously dataclasses attempted to look up the current class' __init__ to find the definition of InitVars, which worked fine as long as the current class was a direct subclass of the parent and didn't override __init__. Unfortunately that didn't work when the InitVar came from a subclass that was not first in MRO, or the parent had an item in its __init__ definition that the subclass didn't use. Now mypy will look up the __init__ for the current parent class that is being processed in order to find the appropriate InitVar.
ilevkivskyi
approved these changes
Dec 19, 2019
beckjake
pushed a commit
to beckjake/mypy
that referenced
this pull request
Dec 27, 2019
In python#8159, I fixed InitVar handling so that it looked up the superclass __init__ and used that to determine the definition of InitVars. That fix doesn't work in the presence of `init=False` subclasses of the initial `init=False` class In that case, the lookup fails because the first attribute reached in MRO order on the subclass is the intermediate class, which also doesn't have the variable in its `__init__`. Then mypy didn't know about the InitVar but still tried to process it as if it did, resulting in an assertion error. This PR fixes that issue by not adding the field to the set of known attrs until an actual definition is found.
JukkaL
pushed a commit
that referenced
this pull request
Jan 9, 2020
…8208) Fixes #8207 In #8159, I fixed InitVar handling so that it looked up the superclass __init__ and used that to determine the definition of InitVars. That fix doesn't work in the presence of `init=False` subclasses of the initial `init=False` class In that case, the lookup fails because the first attribute reached in MRO order on the subclass is the intermediate class, which also doesn't have the variable in its `__init__`. Then mypy didn't know about the InitVar but still tried to process it as if it did, resulting in an assertion error. This PR fixes that issue by not adding the field to the set of known attrs until an actual definition is found.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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 #8015
Fixes #8022
This fixes two bugs related to dataclass
InitVars and overriding__init__by changing mypy to ignore
InitVars in parent classes whenthe class supplied its own
__init__and set(init=False)on the dataclass.It also fixes a bug with multiple inheritance of dataclasses.
Previously dataclasses attempted to look up the current class'
__init__to findthe definition of
InitVars, which worked fine as long as the current class wasa direct subclass of the parent and didn't override
__init__.Unfortunately that didn't work when the
InitVarcame from a subclass that wasnot first in MRO, or the parent had an item in its
__init__definition thatthe subclass didn't use.
Now mypy will look up the
__init__for the current parent class that is beingprocessed in order to find the appropriate
InitVardefinition.I've added test cases for all the issues.