float missing .0 in the pop-up window

[yuxqiu]

Environment data

• Language Server version: 2023.2.40
• OS and version: darwin arm64
• Python version (and distribution if applicable, e.g. Anaconda): Python 3.10.9
• python.analysis.indexing: null
• python.analysis.typeCheckingMode: basic

Code Snippet

def f(x = 1.0):
    return x

Repro Steps

1. Hover the mouse over the function

Expected behavior

It should show (function) def f(x: float = 1.0) -> float, which respects what I wrote in the function.

Actual behavior

The .0 is missing. It only shows (function) def f(x: float = 1) -> float.

Notes

This problem exists for all floating point numbers ending in ".0" (e.g. 1.0, 2., ...).

[debonte]

@erictraut, I thought I remembered seeing a comment from you on an old issue saying that this is by design, but I can't find it.

[erictraut]

This is purely a display issue, so it has no impact on type analysis, so the pylance team should decide how best to display numbers in expressions. Currently, the expression printing logic prints the value of the numeric literal, and it uses standard numeric formatting. That means 1.0, 1.00, 1e0, 0x1, and 0o1 will all be displayed as 1.

We could print the exact text that was found in the source file rather than computing its value. I see pros and cons to both approaches.

I think the options are:

1. Leave it as is and continue to print the value. Optionally move this to discussion to see if we receive additional input.
2. Continue to print the value but provide special formatting that adds a .0 on the end if it's a float value that otherwise fits within an integer.
3. Display the exact text as found in the source file.

Keep in mind that the expression printing logic is also used for logs and some error messages, so all of those would be affected by a change here.

[yuxqiu]

The reason I think this is a problem from a user perspective is that it sometimes makes me think I accidentally declared the default value as int instead of float (because there is no way to distinguish between the two). So when I run into this, I usually have to go to the definition to make sure it is indeed float.

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.

[NickCrews]

I just ran into a similar issue in #6608 (comment), where long ints such as max_pairs: int = 1_000_000_000 get printed as 1000000000, making it really hard to count the 0s.

EDIT: oh, it looks like this isn't open source? :(

@erictraut if you point me towards the files that should get changed, I can file a PR that does the basic changes here. I will start with the simple solution that you suggest, that only affects the printing code:

Continue to print the value but provide special formatting that adds a .0 on the end if it's a float value that otherwise fits within an integer.

I don't see how this would be a regression in any case, and I bet it solves 80% of the need without resorting to needing to find the source text.