Skip to content

Don't suggest Foo[...] when Foo(arg=...) is used in annotation#21238

Open
yosofbadr wants to merge 1 commit intopython:masterfrom
yosofbadr:fix/error-message-callable-type
Open

Don't suggest Foo[...] when Foo(arg=...) is used in annotation#21238
yosofbadr wants to merge 1 commit intopython:masterfrom
yosofbadr:fix/error-message-callable-type

Conversation

@yosofbadr
Copy link
Copy Markdown

Summary

Fixes #16506

When a function call with keyword arguments appears in a type annotation (e.g., Foo(sort=True)), mypy was suggesting use Foo[...] instead of Foo(...). This suggestion is misleading because Foo[sort=True] is a syntax error -- the user likely intended a function call (e.g., returning Annotated[...]), not a type parameterization.

This PR changes the behavior so that:

  • When keyword arguments are present (e.g., Foo(sort=True)), mypy shows Cannot use a function call in a type annotation instead of the misleading Foo[...] suggestion.
  • When only positional arguments are used (e.g., Foo(int)), the existing Suggestion: use Foo[...] instead of Foo(...) message is preserved, since the user likely meant Foo[int].

Changes

  • mypy/fastparse.py: In visit_Call, check e.keywords before choosing which note to attach. If the call has keyword arguments, use a generic "cannot call" message instead of suggesting bracket syntax.
  • test-data/unit/check-fastparse.test: Added a test case for the keyword argument scenario.

Test plan

  • Existing test testFasterParseTypeErrorCustom_no_native_parse still passes (positional args get Foo[...] suggestion)
  • New test testFasterParseCallWithKeywordArgs_no_native_parse passes (keyword args get "Cannot use a function call" message)
  • All 39 fastparse-related tests pass
  • Manual verification with reproduction script from the issue

When a function call with keyword arguments appears in a type
annotation (e.g. `Foo(sort=True)`), mypy was suggesting to use
`Foo[...]` instead. This suggestion is misleading because
`Foo[sort=True]` is a syntax error -- the user likely intended a
function call, not a type parameterization.

Now, when keyword arguments are present, mypy shows "Cannot use a
function call in a type annotation" instead. The `Foo[...]` suggestion
is preserved for calls with only positional arguments (e.g. `Foo(int)`)
where the user likely meant `Foo[int]`.

Fixes python#16506
@github-actions
Copy link
Copy Markdown
Contributor

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:22: note: Cannot use a function call in a type annotation
- ibis/backends/datafusion/udfs.py:30: note: Suggestion: use dt.Timestamp[...] instead of dt.Timestamp(...)
+ ibis/backends/datafusion/udfs.py:30: note: Cannot use a function call in a type annotation
- ibis/backends/datafusion/udfs.py:42: note: Suggestion: use dt.Timestamp[...] instead of dt.Timestamp(...)
+ ibis/backends/datafusion/udfs.py:42: note: Cannot use a function call in a type annotation
- ibis/backends/datafusion/udfs.py:50: note: Suggestion: use dt.Timestamp[...] instead of dt.Timestamp(...)
+ ibis/backends/datafusion/udfs.py:50: note: Cannot use a function call in a type annotation
- ibis/backends/datafusion/udfs.py:111: note: Suggestion: use dt.Timestamp[...] instead of dt.Timestamp(...)
+ ibis/backends/datafusion/udfs.py:111: note: Cannot use a function call in a type annotation

@yosofbadr yosofbadr marked this pull request as ready for review April 15, 2026 20:20
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.

1 participant