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 <jokerjoke...@gmail.com> 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 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/
>
-- 
--Guido (mobile)
_______________________________________________
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/2NOFHHHQSMPOEBPCYU4IE5OGMSYV24FS/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to