Repository navigation
Fix type evaluation of generator expressions inside contextually typed list/set literals (#11841) - #11895
Closed
Peter Hayes (HTMLPETE) wants to merge 1 commit into
Closed
Fix type evaluation of generator expressions inside contextually typed list/set literals (#11841)#11895Peter Hayes (HTMLPETE) wants to merge 1 commit into
Peter Hayes (HTMLPETE) wants to merge 1 commit into
Conversation
…d list/set literals (microsoft#11841) When evaluating list entries against an expected type, Pyright treated all Comprehension nodes as list comprehensions whose elements must match the expected list element type. However, a parenthesized generator expression inside a list literal (e.g. [1, 2, (i for i in range(4))]) is parsed as a Comprehension node with isGenerator === true. Because its runtime type is Generator[T, None, None], it should not be treated as an unpackable sequence or have its yield type extracted directly. This fix checks !entry.d.isGenerator before treating the node as a comprehension element, ensuring the expression is properly typed as a Generator and flagged if incompatible with the expected list element type. Fixes microsoft#11841. Signed-off-by: Peter Hayes <peter@ribbsaetersystems.com>
Author
|
@microsoft-github-policy-service agree |
Collaborator
🟢 Pyright CLI QA —
|
Member
|
/benchmark |
Contributor
|
According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅ |
Collaborator
|
Thanks for the fix. I'm closing this in favor of #11889, which was opened first and has the identical patch, including regression coverage. |
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.
Summary
Addresses #11841.
When evaluating list or set entries against a contextual expected type (e.g.
a: list[int] = [1, 2, (i for i in range(4))]), Pyright treated allParseNodeType.Comprehensionentries as sequence comprehensions, evaluating their yield element against the container element type.However, a parenthesized generator expression inside a list literal is parsed as a
ComprehensionAST node withisGenerator === true. At runtime, its evaluated value is an instance oftypes.GeneratorType(Generator[T, None, None]), not an unpacked sequence ofT.This change adds a check for
!entry.d.isGeneratorintypeEvaluator.tsbefore delegating togetElementTypeFromComprehension. Generator expressions are thus evaluated through standard expression typing asGeneratorinstances, correctly diagnosing type incompatibilities against declared collection element types.Changes
packages/pyright-internal/src/analyzer/typeEvaluator.ts: Guardentry.nodeType === ParseNodeType.Comprehensionwith&& !entry.d.isGeneratorduring contextual list entry evaluation.packages/pyright-internal/src/tests/samples/list1.py: Added regression test case for generator expressions inside typed list literals.packages/pyright-internal/src/tests/typeEvaluator6.test.ts: Updated diagnostic expectation count from 3 to 4.Validation
upstream/main.npx jest src/tests/typeEvaluator6.test.tspassed: 169/169 tests passing (includingList1).npx prettier -cpassed on all modified files with zero formatting discrepancies.