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: #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?

@gaborbernat:

I don't know if this was ever taken to python-ideas, so I'll continue here.

I don't think there is any chance we can override the __repr__ API to add an optional parameter indicating some limit. For the parameter to be usable it needs to be supported by every __repr__ implementation, since the debugger presumably has to call repr(x, limit=N) which must call x.__repr__(limit=N), and if x.__repr__ doesn't support the limit parameter this will raise TypeError. Using introspection to determine whether a particular class' __repr__ implementation has a limit parameter is cumbersome and unreliable, and there's no way to do this for types implemented in C.

Consequently the only way to do this would be to define a new API (strawman: __repr_with_limit__) that types can optionally implement. This is a really high bar (there are lots of other things we would want if we could add a new repr-like dunder) and would require a really well-written PEP supported by high-ranking core devs.

Alternatively, you could lobby for specific improvements to pprint or reprlib (both of which seem to be halfway there). In particular it would seem that if we make one or the other extensible so that user code can register additional handlers for its own types. This is somewhat similar to defining a new dunder but as a feature request for either pprint or reprlib it is much easier to get this idea approved. I don't know exactly what your use case is, so please look at these two modules carefully and come back with a specific proposal.

I think @Elizaveta239 would be able to describe better what she had in mind 👍

Hi @gvanrossum! Thank you for your explanation and for the suggestions! Looks like reprlib does exactly what we need inside our debugger! I don't know how I missed it, but we really can use it without adding any new API into Python. Thank you very much!