Skip to content

Suppress misleading Foo[...] suggestion for annotations with keyword args#21179

Open
Chessing234 wants to merge 1 commit intopython:masterfrom
Chessing234:fix/issue-16506
Open

Suppress misleading Foo[...] suggestion for annotations with keyword args#21179
Chessing234 wants to merge 1 commit intopython:masterfrom
Chessing234:fix/issue-16506

Conversation

@Chessing234
Copy link
Copy Markdown

Summary

  • Fixes Mypy shoould not suggest Foo[...] if annotation contains Foo(arg=...) etc. #16506
  • When a call expression with keyword arguments is used in a type annotation (e.g., Foo(arg=val)), mypy previously suggested use Foo[...] instead of Foo(...). Since Foo[arg=val] is a SyntaxError in Python, this suggestion is misleading.
  • This PR suppresses the bracket syntax suggestion when the call node contains keyword arguments. The "Invalid type comment or annotation" error is still emitted, just without the unhelpful note.

Changes

  • mypy/fastparse.py: Added a check for e.keywords in visit_Call so the Suggestion: use Foo[...] instead of Foo(...) note is only shown when there are no keyword arguments.
  • test-data/unit/check-fastparse.test: Added test case testFasterParseTypeErrorCustomWithKeyword verifying no suggestion note is emitted for Foo(arg=int).
  • test-data/unit/check-errorcodes.test: Added test case testErrorCodeSyntaxError4 verifying the error code behavior with keyword arguments.

Test plan

  • testFasterParseTypeErrorCustom_no_native_parse still passes (existing behavior preserved for positional args)
  • testFasterParseTypeErrorCustomWithKeyword_no_native_parse passes (new test for keyword args)
  • testErrorCodeSyntaxError4_no_native_parse passes (new error code test)
  • All testErrorCodeSyntaxError* tests pass

🤖 Generated with Claude Code

When a call expression with keyword arguments is used in a type
annotation (e.g., `Foo(arg=val)`), mypy previously suggested using
`Foo[...]` instead. However, `Foo[arg=val]` is a SyntaxError in
Python, making the suggestion misleading. This change suppresses the
bracket syntax suggestion when the call contains keyword arguments.

Fixes python#16506

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Apr 6, 2026

Diff from mypy_primer, showing the effect of this PR on open source code:

ibis (https://github.com/ibis-project/ibis)
- ibis/backends/datafusion/udfs.py:22: note: Suggestion: use dt.Timestamp[...] instead of dt.Timestamp(...)
- ibis/backends/datafusion/udfs.py:30: note: Suggestion: use dt.Timestamp[...] instead of dt.Timestamp(...)
- ibis/backends/datafusion/udfs.py:42: note: Suggestion: use dt.Timestamp[...] instead of dt.Timestamp(...)
- ibis/backends/datafusion/udfs.py:50: note: Suggestion: use dt.Timestamp[...] instead of dt.Timestamp(...)
- ibis/backends/datafusion/udfs.py:111: note: Suggestion: use dt.Timestamp[...] instead of dt.Timestamp(...)

@wyattscarpenter
Copy link
Copy Markdown
Contributor

Your two tests seems redundant with each other 🤷‍♂️

@wyattscarpenter
Copy link
Copy Markdown
Contributor

Repeating my suggestion from the main issue discussion, since it's also relevant here:

Assuming we can't/won't make calling the function in the annotation just work, if the problem mypy is trying to help you with is that people write Foo(arg=x) when they mean Foo[x], then isn't an additional suggestion called for? Like, keep the note: Suggestion: use Foo[...] instead of Foo(...), but add an additional note: Cannot use named arguments as type arguments. This could even fire orthogonally, as another note on invalid-type, whenever named arguments are used. According to 87f1588 this should be a pretty simple feature to implement. If we can make both of those not appear, and be replaced with note: Can't call a function in a type annotation if mypy determines the call is actually to a function, even better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Mypy shoould not suggest Foo[...] if annotation contains Foo(arg=...) etc.

2 participants