[SciPy-Dev] Custom __repr__?

[Robert Kern]

On Thu, May 13, 2021 at 10:29 PM Andrew Nelson <andyfaff at gmail.com> wrote:

> On Fri, 14 May 2021 at 11:40, Robert Kern <robert.kern at gmail.com> wrote:
>
>>
>> You'll run into more such objects. Having a round-trippable `__repr__()`
>> isn't all that common. Even `ndarray` will trip you up
>> with its summarization. And that's not even considering what kind of
>> imports you need to have done in order for even the eval()able
>> representations to actually evaluate. You will probably need to incorporate
>> a subsystem in your code generation to get eval()able string
>> representations of the objects you care about.
>>
> You can often bound the effort a bit more than what the class author would
>> need to do since you likely only deal with a subset of functionality (do
>> you need eval()able datetime64 arrays? Probably not. Do you
>> need array parameter arguments to the distributions or just scalars?
>> Maybe). You'll need that to make sure the imports are there in any case.
>>
>
> I have __repr__ for all the major classes I need to care about, and I know
> which imports I need for the code generation (they're pretty much fixed). I
> just use the name of the object in the __repr__ (norm), rather than the
> name of the object with the full import path (scipy.stats.norm). In my case
> I do need to use 'simple' numpy arrays in the code generation, but they're
> directly loaded from datafiles rather than having a __repr__.  I don't need
> datetime64 arrays.
>

The remark about datetime64 arrays was rhetorical. :-) I was just
demonstrating that you are in a position to make simplifying assumptions
that we often can't make. It's a good idea for you to own your code
generation in any case. You can write what you need in there without
needing our __repr__ to do anything.


> My requirements would be to have a __repr__ for frozen rv_continuous
> distributions with scalar shape parameters. I hadn't appreciated before
> that rv_continuous could be frozen with scale/loc/shape parameters that
> were array rather than scalar. I agree that it's a major hassle to get a
> __repr__ of a numpy array. Perhaps Pamphiles suggestion of
> ```
> f"{dist.dist.name}(*{dist.args!r}, **{dist.kwds!r})"
> ```
>
> would work as a good general __repr__, with more specific implementations
> as required. This would have the specific proviso that roundtripping would
> work for scalar cases, but not for array scale/loc/shape cases.
>

That would work for something like quick-and-dirty code generation, but it
will look awful on the prompt, and that's where I would want our use cases
geared towards. To me, the main use case for a (roughly)
eval()able __repr__ is to allow users to copy-paste an Out[] cell for use
elsewhere, not for mechanical eval()ing. It's not hard to fix to assemble
the args and kwds into what users would naturally type; it's just not a
one-liner.

-- 
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20210513/15a44504/attachment.html>