You could do it with a custom function, however the hope in this e-mail thread was that the language should agree on this function name, and ideally should be __str__/__repr__ with an optional argument. And then we should implement stdlib types to follow this custom logic (think e.g. of repr-ing an array that has lots of values).
On Fri, Jul 24, 2020 at 5:59 PM Paul Moore <p.f.mo...@gmail.com> wrote: > On Fri, 24 Jul 2020 at 16:15, Gábor Bernát <jokerjoke...@gmail.com> wrote: > > > > Hello, I'd like to bring to your attention > https://bugs.python.org/issue41383. The core idea here is per Elizaveta > Shashkova: > > > > 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. > > Maybe repr is not the best here, because that should be interpreter > meaningful, but instead the __str__ method that's better for this. Maybe we > could pass in an optional limit argument to these methods, so that the user > can decide what to print depending on how many characters he has left? > > > > Any takes, better ideas how we could help this problem? > > Why not just use a custom function for this? I don't understand why > this has to be coupled to repr, or indeed to anything that's special > to the repr. > > The debugger (presumably a custom application) could call a custom > function to generate the string representation, and that function > could have any API it wants. The default implementation of the > function (functools.singledispatch seems like it would be ideal for > this) could just call repr, so that objects that don't need special > treatment would use repr. > > This doesn't seem like it's something that should need language support at > all. > > Paul >
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KVAZJCNLO7N7DHGGTV6FYPRDKKUP7EY6/ Code of Conduct: http://python.org/psf/codeofconduct/
