Title: Provide a limit arguments for __repr__
Type: Stage:
Components: Interpreter Core Versions: Python 3.10
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Bernat Gabor, eric.smith, remi.lapeyre, rhettinger
Priority: normal Keywords:

Created on 2020-07-24 14:04 by Bernat Gabor, last changed 2020-07-26 17:51 by rhettinger.

Messages (4)
msg374179 - (view) Author: Bernat Gabor (Bernat Gabor) * Date: 2020-07-24 14:04
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?
msg374182 - (view) Author: Rémi Lapeyre (remi.lapeyre) * Date: 2020-07-24 14:10
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:

Alternatively, I think pprint.pformat() may be useful for your purpose too.
msg374191 - (view) Author: Bernat Gabor (Bernat Gabor) * Date: 2020-07-24 15:03
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.
msg374335 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2020-07-26 17:50
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?
Date User Action Args
2020-07-26 17:51:07rhettingersetnosy: + eric.smith
2020-07-26 17:50:51rhettingersetnosy: + rhettinger
messages: + msg374335
2020-07-24 15:03:58Bernat Gaborsetmessages: + msg374191
2020-07-24 14:10:04remi.lapeyresetnosy: + remi.lapeyre
messages: + msg374182
2020-07-24 14:04:53Bernat Gaborcreate