Fix lambda contextual typing with keyword-only callables by vetrovk · Pull Request #11609 · microsoft/pyright

Kirill (vetrovk) · 2026-08-09T09:05:18Z

When a lambda was contextually typed from a union of callable candidates, a keyword-only parameter from one candidate could incorrectly provide the type for a positional lambda parameter. This caused the wrong candidate to influence inference instead of being rejected.

Treat a keyword-only contextual parameter as compatible only with a lambda parameter that follows * or *args. Otherwise, skip that candidate and continue with the remaining contextual signatures.

Tests cover the reported case, generic and callback-protocol variants, ordinary callable unions, positional callable objects, and the incompatible keyword-only case.

Validation:

Lambda4: 1/1 passed
lambda subset: 16/16 passed
typeEvaluator1.test.ts: 159/159 passed
npm run build:cli:dev
Prettier
ESLint
git diff --check

Stella Huang (StellaHuang95) · 2026-08-10T03:26:31Z

🔒 Automated review in progress — Stella Huang (@StellaHuang95) is auto-reviewing this PR.

Stella Huang (StellaHuang95) · 2026-08-10T03:36:25Z

+positional_callable_union: Callable[[PositionalCallable], PositionalCallable] | PositionalCallable = lambda x: x
+
+# This should generate an error.
+keyword_only_callback: KeywordOnlyCallback = lambda x: x


Warning · Non-blocking recommendation

Add a positive regression case for the enabled branch: a lambda with *args followed by a keyword-only parameter contextually typed against a keyword-only callable. The new guard's rejection behavior is well covered, but this ensures valid keyword-only lambda parameters still receive their expected type.

[verified]

Stella Huang (StellaHuang95) · 2026-08-10T03:36:28Z

                        if (
                            expectedParam.param.category === param.d.category &&
-                            !param.d.name === !expectedParam.param.name
+                            !param.d.name === !expectedParam.param.name &&


Warning · Non-blocking recommendation

This guard also prevents contextual typing for a compatible single callable such as Callable[*, value: int] assigned from lambda value: value: that lambda accepts the required value= keyword, but its parameter now falls back to Unknown. Please preserve contextual typing when the lambda parameter name matches the keyword-only expected parameter, or add coverage showing why this case must be rejected.

[verified]

Stella Huang (StellaHuang95) · 2026-08-10T03:36:31Z

Please mirror the keyword-only lambda-parameter compatibility guard in packages/pylance-internal/src/analyzer/typeEvaluator.ts; the current diff updates only the Pyright evaluator, so async Pylance users retain the bug.

Stella Huang (StellaHuang95) · 2026-08-10T04:48:56Z

+                                isPrivateName(param.d.name.d.value));
+                        const isCompatibleKeywordParam =
+                            expectedParam.kind !== ParamKind.Keyword ||
+                            sawLambdaArgsParam ||


Info · Optional note

isPositionOnlyParam reads paramsArePositionOnly, which is mutated later in this loop. It is correct today, but that coupling makes the matching behavior sensitive to loop ordering. Consider deriving this status up front from node.d.params, alongside positionOnlySeparatorIndex, so future refactoring cannot silently change contextual-typing behavior.

[verified]

Stella Huang (StellaHuang95)

Approved via Review Center.

Rich Chiodo (rchiodo)

Approved via Review Center.

Rich Chiodo (rchiodo)

Approved via Review Center.

Rich Chiodo (rchiodo) · 2026-08-17T11:48:36Z

🔒 Automated review in progress — Rich Chiodo (@rchiodo) is auto-reviewing this PR.

Rich Chiodo (rchiodo) · 2026-08-17T19:29:15Z

                        const expectedParam = expectedParamDetails.params[index];
+                        const isPositionOnlyParam =
+                            (positionOnlySeparatorIndex >= 0 && index < positionOnlySeparatorIndex) ||
+                            (positionOnlySeparatorIndex < 0 &&


Warning · Non-blocking recommendation

A bare * appears to consume an index even though contextual parameter details omit separators, potentially leaving lambda *, value: ... without the contextual type for value. Add that protocol scenario with assert_type(value, int) and, if confirmed, track lambda and contextual indexes separately.

Rich Chiodo (rchiodo) · 2026-08-17T19:29:18Z

+                                paramsArePositionOnly &&
+                                !!param.d.name &&
+                                isPrivateName(param.d.name.d.value));
+                        const isCompatibleKeywordParam =


Warning · Non-blocking recommendation

Once sawLambdaArgsParam is true, any keyword-only contextual parameter is accepted regardless of its name, so lambda *args, other: ... may inherit the type of contextual value. Add a callable-union regression using assert_type(other, ...); require matching names after *args if the candidate can otherwise influence inference.

Rich Chiodo (rchiodo) · 2026-08-17T19:29:22Z

                FunctionType.addParam(functionType, functionParam);
+
+                if (param.d.category === ParamCategory.ArgsList) {
+                    sawLambdaArgsParam = true;


Warning · Non-blocking recommendation

Pylance's parallel evaluator still contains the previous matching condition, so vendoring this change without mirroring it could produce sync/async inference differences. Ensure the downstream ingestion updates that evaluator and runs this regression in both modes.

Rich Chiodo (rchiodo)

Approved via Review Center.

Heejae Chang (heejaechang)

Approved via Review Center.

Rich Chiodo (rchiodo) · 2026-08-24T17:37:28Z

            node.d.params.forEach((param, index) => {
                let paramType: Type | undefined;

                if (expectedParamDetails && !sawParamMismatch) {


Issue · Please address or respond

Can the unnamed bare * be normalized separately from the contextual parameter index? If getParamListDetails omits that separator, lambda *, value: ... compares * with the expected value parameter, marks a mismatch, and never contextually types value. Please skip or align the separator and add this regression case.

Rich Chiodo (rchiodo) · 2026-08-24T17:37:32Z

+                            sawLambdaArgsParam ||
+                            (!isPositionOnlyParam && param.d.name?.d.value === expectedParam.param.name);

                        // If the parameter category matches and both of the parameters are


Issue · Please address or respond

Can this continue to require matching keyword names after *args? sawLambdaArgsParam currently accepts every following keyword-only expected parameter regardless of name, but lambda *args, value: ... does not accept other=.... This can let an incompatible union candidate provide contextual types; retain the name check and add a differing-keyword-name regression.

Rich Chiodo (rchiodo) · 2026-08-24T17:37:37Z

Verification: The relevant tests could not be fully run in the isolated environment; this review is not fully verified.

Rich Chiodo (rchiodo) · 2026-08-24T18:26:24Z

+                            (!isPositionOnlyParam && param.d.name?.d.value === expectedParam.param.name);

                        // If the parameter category matches and both of the parameters are
                        // either separators (/ or *) or not separators, copy the type


Warning · Non-blocking recommendation

isPositionOnlyParam depends on paramsArePositionOnly, which is mutated during iteration and makes matching sensitive to loop ordering. Precompute each lambda parameter's positional-only status before contextual matching.

[verified]

Rich Chiodo (rchiodo) · 2026-08-24T18:26:28Z

Verification: The relevant tests could not be fully run in the isolated environment; this review is not fully verified.

Fix lambda contextual typing with keyword-only callables

92dedae

Stella Huang (StellaHuang95) reviewed Aug 10, 2026

View reviewed changes

Stella Huang (StellaHuang95) added the review-auto:changes-requested Automated review: posted blocking findings to address. label Aug 10, 2026

Preserve matching keyword lambda context

32b885d

Stella Huang (StellaHuang95) reviewed Aug 10, 2026

View reviewed changes

Stella Huang (StellaHuang95) approved these changes Aug 10, 2026

View reviewed changes

Stella Huang (StellaHuang95) added review-auto:approved Automated review: no blocking findings (approval posted). and removed review-auto:changes-requested Automated review: posted blocking findings to address. labels Aug 10, 2026

Rich Chiodo (rchiodo) approved these changes Aug 10, 2026

View reviewed changes

Rich Chiodo (rchiodo) approved these changes Aug 11, 2026

View reviewed changes

Rich Chiodo (rchiodo) reviewed Aug 17, 2026

View reviewed changes

Rich Chiodo (rchiodo) approved these changes Aug 17, 2026

View reviewed changes

Heejae Chang (heejaechang) approved these changes Aug 17, 2026

View reviewed changes

Rich Chiodo (rchiodo) reviewed Aug 24, 2026

View reviewed changes

Rich Chiodo (rchiodo) added review-auto:changes-requested Automated review: posted blocking findings to address. and removed review-auto:approved Automated review: no blocking findings (approval posted). labels Aug 24, 2026

Fix lambda keyword-only parameter matching

e016c03

Rich Chiodo (rchiodo) reviewed Aug 24, 2026

View reviewed changes

Rich Chiodo (rchiodo) approved these changes Aug 24, 2026

View reviewed changes

Rich Chiodo (rchiodo) added review-auto:approved Automated review: no blocking findings (approval posted). and removed review-auto:changes-requested Automated review: posted blocking findings to address. labels Aug 24, 2026

Uh oh!

Conversation

Kirill (vetrovk) commented Aug 9, 2026

Uh oh!

Stella Huang (StellaHuang95) commented Aug 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Stella Huang (StellaHuang95) commented Aug 10, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Stella Huang (StellaHuang95) left a comment

Choose a reason for hiding this comment

Uh oh!

Rich Chiodo (rchiodo) left a comment

Choose a reason for hiding this comment

Uh oh!

Rich Chiodo (rchiodo) left a comment

Choose a reason for hiding this comment

Uh oh!

Rich Chiodo (rchiodo) commented Aug 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Rich Chiodo (rchiodo) left a comment

Choose a reason for hiding this comment

Uh oh!

Heejae Chang (heejaechang) left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Rich Chiodo (rchiodo) commented Aug 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Rich Chiodo (rchiodo) commented Aug 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Stella Huang (StellaHuang95) commented Aug 10, 2026 •

edited

Loading

Rich Chiodo (rchiodo) commented Aug 17, 2026 •

edited

Loading