Debug output and watches don't use custom repr()/str() for long strings?

[ldorigo]

Issue Type: Bug

Hi, consider this small snippet:

from typing import NamedTuple


class Test(NamedTuple):
    a: str
    b: str
    c: str

    def __str__(self):
        return f"{self.a} {self.b} {self.c}"

    def __repr__(self) -> str:
        return str(self)

test_works = Test("a","b","c")
test_doesntwork = Test("a", "b", "potato" * 15)
print(test)

If I add test_works to watches or evaluate it in the debug console, it correctly uses the repr() I provide. However after some arbitrary string length, it reverts to showing <Test, len() = 3> - which I don't want. I tried looking for a setting to change the value at which this change happens but couldn't find any. This is quite annoying when debugging as I need to continuously focus the output window and type print(test_doesntwork) to be able to see what's in it.

Extension version: 2022.0.1786462952
VS Code version: Code 1.64.0 (5554b12acf27056905806867f251c859323ff7e9, 2022-02-03T04:23:11.224Z)
OS version: Linux x64 5.15.19-1-lts
Restricted Mode: No

System Info

Item	Value
CPUs	AMD Ryzen 7 3700X 8-Core Processor (16 x 3600)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software skia_renderer: enabled_on video_decode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	0, 1, 1
Memory (System)	31.36GB (3.09GB free)
Process Argv	--crash-reporter-id 66ea3ec9-05eb-4edd-8d35-34bbe6c1aba1
Screen Reader	no
VM	0%
DESKTOP_SESSION	plasma-i3
XDG_CURRENT_DESKTOP	KDE
XDG_SESSION_DESKTOP	KDE-i3
XDG_SESSION_TYPE	x11

[gramster]

@karthiknadig, I assume because you moved this here the truncated form is happening in debugpy or pydevd, and it's not VS Code that is deciding that the string is too long and asking for a shorter representation?

[karthiknadig]

That is correct, pydevd has a limit to the number of characters returned from strings. I think here:

debugpy/src/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_safe_repr.py

Line 33 in 0dd74a7

maxstring_inner = 30

[karthiknadig]

This limit applies to the inner string, in the above case, the "potato" * 15 gets treated as inner string. If it was just string, instead of a tuple, then the limit is 2**16

[int19h]

And we need to do this to avoid accidentally sending a multi-megabyte string over DAP, even if the client ultimately truncates it. We could up the limits, though.

[ldorigo]

Hi, did you close this because you did in fact change the limit? Or were you waiting for a reaction?

I think it would make sense to increase the limit - ideally it could be set by the user (as a setting in vscode - and maybe a CLI flag for debugpy) but that's likely much more work. Since it looks like you're already setting the outer string length limit (which would avoid excessive bandwidth use), it should be fine with increasing the inner limit?

And we need to do this to avoid accidentally sending a multi-megabyte string over DAP

Ps: for my own curiosity, what's DAP? Nothing on wikipedia's disambiguation page seems to fit :-)

[karthiknadig]

@ldorigo https://microsoft.github.io/debug-adapter-protocol/specification

[int19h]

Yes, we need more feedback on the limits first. Keep in mind that making them longer means that reprs for some deeply nested structures might become less readable, so we need to find the right balance.

You can directly edit the file that Karthik mentioned earlier in your installation of vscode-python (look under pythonFiles) to see how the different limits affect output. It would be great if you could do that and share the optimal limits for your data and layout - with enough datapoints like that, we can get a clearer picture.

In the meantime, perhaps we could change the hardcoded values to os.environ[...] to provide at least some way to control those without manually editing the code? It's not as nice as integrating it with launch.json, but it's also much easier to implement.

[jmehnle]

My __repr__ is generating a string that's less than 30 characters, and yet what the VS Code debugger shows me is: <MyClass object at 0x10de564e0>, which is not at all what __repr__ returns.

It turned out that my __repr__ was decorated with @functools.cache, and VS Code didn't like that. Once I removed the decorator, the generated string showed up in the debugger.

[int19h]

You can see the exact code that is used to compute the representation in Variables pane here: https://github.com/microsoft/debugpy/blob/main/src/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_safe_repr.py

As you can see, unless the value is one of the few specially handled built-in types, it just calls repr() on it and uses the value, except if repr() throws, in which case it falls back to object.__repr__() instead - this is likely what is happening here.