I do expect some difference between reveal_type and on-hover where on-hover will only show the signature (but not the type) for classes, functions, methods, and maybe more. E.g. pyright renders a function as def foo(a: int) -> str

This description seems backwards to me from pyright's actual behavior? For a function literal f, pyright renders it on-hover as "(function) def f(x: int) -> str", and on reveal_type gives just (x: int) -> str. I'm not too bothered by that minimal level of difference, though I also don't see any strong rationale not to include the function name in reveal_type and make them even more similar. I think we should keep them identical until/unless we have strong and clear reasons to do otherwise.

I was assuming we are just changing from Literal[some_type.some_bound_symbol] to (args...) -> return_ty for reveal_type and by extension LSP.

I would be inclined to include the function name for a function literal (as that's one of the few things that distinguishes it from a general callable type), so more like f(x: int) -> str. But otherwise yes, your assumption matches my intention in filing this issue.

Yes. But I've already done such things, I am fine doing this as long as we quickly merge a PR, so I do not have to constantly update test files as main is moving ahead.

Thank you, and makes sense. The one thing I would suggest is to first push just the change without the mdtest updates and make sure we are all happy with how the new format looks in all tested cases (with the new inline mdtest failures on CI, it will be easy to see the differences even if mdtests are failing). Once we are confirmed happy with the new format, then update the mdtests and land immediately.

[red-knot] improve function and class literal type display #17238

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions