gh-133956 fix bug where dataclass wouldn't detect ClassVar fields if ClassVar was re-exported from a module other than typing
#140541
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.
This PR continues work by @dzherb from #134073.
I've simplified the code and removed strict checks from
_is_type. Supporting arbitrary levels of module nesting turned out to be beneficial for overall code complexity, so I've included it to this PR; I can send it as a separate PR with a separate issue, though.Motivation for current implementation
I think we shouldn't assume anything about user-provided type annotations. All we know from annotation
ty.ClassVaris that there is an objectty, and we're getting its attributeClassVar. We shouldn't assume thattyis a module, nor that it doesn't implement some custom__getattr__logic; instead, we should just do what the annotation tells us to do.dataclasses: Synthetic__init__method on dataclass has brokenClassVarannotation under some conditions. #133956