26.07.20 01:41, Greg Ewing пише:
On 26/07/20 1:34 am, Elizabeth Shashkova wrote:
1. We need this lazy `__repr__` calculation inside our debugger, where
we work with different user's objects. Usually it isn't some specific
type, for which you know that it'll be big and its `__repr__`
calculatio
Well, about pprint, the solution is not easy... but about debugging, pytest
for example does not show the full repr of an object, if the object is too
large. You have to run pytest with the flag -v or -vv. Maybe that code
could be moved in a separate little library.
Another simple solution could b
On 26/07/20 1:34 am, Elizabeth Shashkova wrote:
1. We need this lazy `__repr__` calculation inside our debugger, where
we work with different user's objects. Usually it isn't some specific
type, for which you know that it'll be big and its `__repr__`
calculation will be slow
Seems to me it wo
Hello,
On Sat, 25 Jul 2020 16:34:16 +0300
Elizabeth Shashkova wrote:
> Hi!
>
> Thanks everyone for the interest and for the suggested options! I
> would like ro add my two coins and clarify some moments as the
> original requester of this feature.
>
> 1. We need this lazy `__repr__` calculatio
Hi!
Thanks everyone for the interest and for the suggested options! I would
like ro add my two coins and clarify some moments as the original requester
of this feature.
1. We need this lazy `__repr__` calculation inside our debugger, where we
work with different user's objects. Usually it isn't s
24.07.20 18:10, Gábor Bernát пише:
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
On Fri, 24 Jul 2020 at 16:43, Gábor Bernát wrote:
>
> While I agree the implementation on how to represent in limited space the
> object should be the responsibility of the project that provides objects of
> long size, I think it's a language-behaviour material what type of solution
> we want t
You may be interested in my library https://github.com/alexmojaki/cheap_repr
It was created precisely for the purpose of generating many reprs quickly
for my debugging libraries.
On Fri, Jul 24, 2020 at 5:17 PM Gábor Bernát wrote:
> Hello, I'd like to bring to your attention
> https://bugs.pyth
But adding an optional parameter to an existing dunder is pretty much the
worst choice. Every existing method of that name would have to be altered,
or you’d end up with horrible code to cope with it — either catching
exceptions or introspection.
On Fri, Jul 24, 2020 at 10:35 Bernat Gabor wrote:
On 7/24/2020 1:33 PM, Bernat Gabor wrote:
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 follo
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
On Fri, 24 Jul 2020 at 16:15, Gábor Bernát 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 objec
On 2020-07-24 at 15:10:46 -,
Gábor Bernát wrote:
> ... 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 real
On Sat, Jul 25, 2020 at 1:18 AM Gábor Bernát 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 obj
While I agree the implementation on how to represent in limited space the
object should be the responsibility of the project that provides objects of
long size, I think it's a language-behaviour material what type of solution we
want to propose/recommend.
That is definitely not language-behavior material - and should be a worry
of the authors of whatever projects have objects that demand so much
processing to generate a "repr".
It certainly is not a common problema met with - I often have to deal
with cumbersome repr's (even in my own projects), b
16 matches
Mail list logo
