[ty] Fix implementation of Top[Callable[..., object]] by charliermarsh · Pull Request #22145 · astral-sh/ruff (original) (raw)
AlexWaygood changed the title
Use gradual form ( [ty] Use gradual form (...) for parameters in Callable bottom type...) for parameters in Callable bottom type
AlexWaygood changed the title
[ty] Use gradual form ( [ty] Use gradual form (...) for parameters in Callable bottom type...) for parameters in Callable top materialization
AlexWaygood changed the title
[ty] Use gradual form ( [ty] Fix implementation of ...) for parameters in Callable top materializationTop[Callable[..., object]]
Co-authored-by: Alex Waygood Alex.Waygood@Gmail.com
Co-authored-by: Alex Waygood Alex.Waygood@Gmail.com
This was referenced
Dec 24, 2025
charliermarsh pushed a commit that referenced this pull request
…ute on a Callable type (#22182)
Summary
Other type checkers allow you to access all FunctionType attributes on
any object with a Callable type. ty does not, because this is
demonstrably unsound, but this is often a source of confusion for users.
And there were lots of diagnostics in the ecosystem report for
#22145 that were complaining that
"Object of type (...) -> Unknown has no attribute __name__", for
example.
The discrepancy between what ty does here and what other type checkers do is discussed a bit in astral-sh/ty#1495. You can see that there have been lots of issues closed as duplicates of that issue; we should probably also add an FAQ entry for it.
Anyway, this PR adds a subdiagnostic to help users out when they hit this diagnostic. Unfortunately something I did meant that rustfmt increased the indentation of the whole of this huge closure, so this PR is best reviewed with the "No whitespace" option selected for viewing the diff.
Test Plan
Snapshot added
KotlinIsland pushed a commit to KotlinIsland/basedpython that referenced this pull request
…ute on a Callable type (#22182)
Summary
Other type checkers allow you to access all FunctionType attributes on
any object with a Callable type. ty does not, because this is
demonstrably unsound, but this is often a source of confusion for users.
And there were lots of diagnostics in the ecosystem report for
astral-sh/ruff#22145 that were complaining that
"Object of type (...) -> Unknown has no attribute __name__", for
example.
The discrepancy between what ty does here and what other type checkers do is discussed a bit in astral-sh/ty#1495. You can see that there have been lots of issues closed as duplicates of that issue; we should probably also add an FAQ entry for it.
Anyway, this PR adds a subdiagnostic to help users out when they hit this diagnostic. Unfortunately something I did meant that rustfmt increased the indentation of the whole of this huge closure, so this PR is best reviewed with the "No whitespace" option selected for viewing the diff.
Test Plan
Snapshot added
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
[ Show hidden characters]({{ revealButtonHref }})