Debug console shows too much detail and too little data information

[WMLKalthof]

Hi all. As the images below shows, the debug console shows too much information when you inspect a variable. Up untill recently, it showed all values when you inspected it, together with some general data like the min or max of the array. This is now impossible, as each dropdown menu has another dropdown menu seemingly ad infinitum.

I have tried following microsoft/ptvsd#1621 , but this only hides the special variables and function variables, while all other options remain and the overall data is still not available (image 2). I have tried reinstalling and resetting VSCode (https://stackoverflow.com/questions/36108515/how-to-reset-settings-in-visual-studio-code second comment) , but to no avail. I am not sure what to try anymore.

[zljubisic]

Debug console is pure disaster with little chance that it will be improved.
Looks like debug console is kind of input mask in which you are placing commands and than behind it is a complicated mechanism how to present the output of the commands that should kind of "help" us.
If they don't do anything and return plain result it would be much better.
For example look at #1084 if they don't interfere there wouldn't be a problem.
Currently I am working on 4k 43" monitor and debug console is limited to 80 characters like this:

Or my favorite, if you print pandas dataframe in debug console and click on one row in order to copy cell value out of it.
It will expand to everything in the world that you don't need.
Haven't figured out how to squeeze this row back in original format yet.

Anyway, good luck. You will need it.

[int19h]

There are different issues at play here.

From the Python debugger perspective, debug console is basically the same logic as Watch. The code that does trimming of values can be seen here:
https://github.com/microsoft/debugpy/blob/ef9a67fe150179ee4df9997f9273723c26687fab/src/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_safe_repr.py

We can apply different limits in cases where the eval is coming from a console, or drop them altogether. But in that case you risk getting in a situation where you try to eval something that would produce a multi-megabyte repr(), and then have to sit and wait until it gets transmitted on the wire and actually printed.

The 80-column line length for the console is not something that we control or interfere with in debugpy tho. It seems rather that VSCode itself decides to wrap output here for unclear reasons; that should be a separate issue on VSCode itself.

[zljubisic]

@int19h Pavel, have you seen debug console in PyCharm.
I used to use PyCharm until two years ago.
Now I am in company that uses vscode.
I would say that vscode is quite good IDE, but some decisions are just wrong.
Whatever you are doing to mitigate the problem can help a bit, but you will always be in new problems.
Debug console is one of it. Big one.

You said: "...you risk getting in a situation where you try to eval something that would produce a multi-megabyte repr()...".

It could be a valid argument, but I would rather wait for muli-megabyte repr() but at the same time not struggle with all limitations of debug console.
Yes, it will hit me few times before I become more careful, but I would accept it.

I know that behind the vscode is a big inert organization on which you don't have an influence. Still, I appreciate your willing to help.

[int19h]

I think this is the kind of trade-off that different people are going to make in different ways. That risk isn't just a theoretical preemptive thing - we had actual bug reports from people who were very confused because their debug session was very slow or outright unresponsive, because one of local variables happened to have an extremely large dataset.

So we should come up with a default that handles the most common use cases in a way that is reasonable for most users dealing with those cases - which I think should be a lot more generous than what we have now! - but we should also make it properly configurable so that if you are okay with the caveats of an unlimited repr, you can live dangerously.

I'm also mulling the idea of a PEP for some kind of a "pull" __repr__ alternative whereby the caller doesn't have to sit and wait for the entire string, but instead can repeatedly ask for the next chunk of it - that would make reprs cancelable, so we could e.g. detect if it takes longer than some specified time and stop it then. But that would be a very long-term solution that hinges on such PEP actually being approved, and then on popular libraries in the ecosystem adopting it. The current situation is inherently hacky, unfortunately; no matter what we do, it won't be the Right Thing in all scenario.

[zljubisic]

Have you study how debug console works in PyCharm?
I don't remember that I had any problem while I was using it.