code action/double click to transition inlay hints to real life

[KotlinIsland]

Before

backticks represent inlay hints

class A: ...
a`: A` = A()

After

class A: ...
a: A = A()

[KotlinIsland]

• As noted by @NCBM in filling inlay hints by double-clicking #317, this is a pylance feature that already exists, triggered by double clicking the inlay hint.

[DetachHead]

something i noticed about pylance's implementation of this feature is that it doesn't work on all inlay hints for some reason. eg:

def f(a: int, /) -> str: ...

x = f  # works

foo = "" # doesn't work

imo inlay hints should always be valid code, so they should always allow double-clicking to insert them

[NCBM]

something i noticed about pylance's implementation of this feature is that it doesn't work on all inlay hints for some reason. eg:

def f(a: int, /) -> str: ...

x = f  # works

foo = "" # doesn't work

Recently I tested the case once doesn't work and it worked now (Pylance v2024.7.1).

Auto-import from typing is even done.

imo inlay hints should always be valid code, so they should always allow double-clicking to insert them

Actually there are also inlay hints which are not valid code, e.g.

a, b = "foo", int()  # `a` is shown nothing while `b` is shown as `int` in inlay hints.

c = 42  # `c` is shown nothing in inlay hints. hovering mouse cursor to see the type.

of course they cannot be inserted.

Another thing we can notice is that some not-quite-useful Literals are sometimes not shown.

[DetachHead]

oops, in my example i had it the wrong way around. it's the Callable inlay hint that doesn't work:

def f(a: int, /) -> str: ...

x = f  # doesn't work

foo = "" # works

related: #199

[NCBM]

maybe Callable inlay hints are considered complex by pylance that should be assigned to a type alias?

[KotlinIsland]

maybe Callable inlay hints are considered complex by pylance that should be assigned to a type alias?

Such a based idea:

def f(a=1, /, *, b=False):
    return 1

a = f

After transition operation:

class F(Protocol): # maybe "A"?
    def __call__(self, a: int = ..., /, *, b: bool = ...) -> int: ...

a: F = f

[npip99]

I personally use inlay for maximum information possible, so I'd rather just max info in all situations (I've never used the feature to bring inlay hints into real life / it wouldn't matter to me personally inlay hints aren't valid syntax)

Could be a config option though, to disable invalid inlay hints; maybe there's an option for the LSP to throw an error dialog if you try an action but it fails, e.g. for trying to bring invalid inlay hints to real life.

If there are two options that provide the same information, but one was valid and the other was invalid, yeah prefer the valid. It would also make more sense.

-> Just my thoughts, not saying that's the avg thought or anything.

[npip99]

Interesting potential edge cases -

It's also keyword arguments that appear but aren't actually keyword. E.g., dt.datetime.fromisoformat(date_string=user.timezone), date_string in this case is not a valid keyword argument.

Inlay hints currently don't use namespaces.

my_datetime: datetime = dt.datetime.fromisoformat(my_str)
In this case, : datetime is an inlay hint, but it should be dt.datetime to namespace correctly. Might be nicer to read dt.datetime too, so that it matches how you're using it in the code (dt.datetime.fromisoformat).

--
Currently also has an effect if e.g. using the mouse to copy code with inlay hints, from a terminal to a repl, which then fails on the repl due to invalid type hint.