Quoting Elizaveta Shashkova from EuroPython 2020 chat about how can we improve debug experience for users:

I would like to have a lazy repr evaluation for the objects! Sometimes users have many really large objects, and when debugger is trying to show them in Variables View (=show their string representation) it can takes a lot of time. We do some tricks, but they not always work. It would be really-really cool to have parameter in repr, which defines max number of symbols we want to evaluate during repr for this object.

What do people, would this optional str limit be a good thing? Does anyone has a better idea?

Hi Bernat, have you looked into reprlib.repr()? It's an alternative implementation of repr() made for cases like this.

You may be interested in this PR too: https://github.com/python/cpython/pull/20925

Alternatively, I think pprint.pformat() may be useful for your purpose too.

Thanks Rémi, did not know about it. Played around with it, and is not entirely what we'd need here. That class still generates the long string repr, just truncates it afterwards. That is unless teh Repr implements custom formatting for the types, however the Repr would be the IDEs code, and that doesn't understand enough the user code to be able to tell what's a good short representation for it. This was the idea with adding it as a parameter to the repr function, that the user can customize/override the outcome depenending how many characters it has left to use up for repr.

I suggest taking this to Python ideas.  While there is a legitimate concern about large objects in a Variable View, the idea impacts long-standing core APIs.  Accordingly, it needs to be thought through, become better specified, and be evaluated against alternatives.  If the language impact is pervasive, it would likely need a PEP as well.

Some questions immediately come to mind:

* Would the existing standard and third party libraries need to recode every __repr__ or __str__ implementation for every container that has ever been written?  Would that include C code as well?

* It there something this limit parameter could do that couldn't already be achieved with __format__()?

* Should limits be a responsibility of individual classes or it is a debugger responsibility?  On the one hand, it is hard to see how a debugger could implement this without blind truncation; on the other hand, I don't think other languages make a similar inversion of responsibility.

* How would the parameter be accessed via the !r and !s codes in f-strings?

* How easy or hard would this be to implement for typical classes, lists for example?

* What is meant by "max number of symbols we want to evaluate"?  Would the repr for ['x'*1_000_000] count as one symbol or as one million?

* For tree-like structures (JSON for example), does a symbol limit make sense?  Wouldn't you want a depth limit instead.

* Would some variant of "..." be added to indicate that limits were applied and to prevent someone for accidentally running eval() on the output?